Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Roy Funderburk <royffmpeg@funderburk.us>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH] avformat/avcodec: Add DTS-UHD demuxer and parser, movenc support.
Date: Wed, 14 Jun 2023 11:24:13 -0700
Message-ID: <443cbb24-1f60-d664-8fa2-cbb35906a51f@funderburk.us> (raw)
In-Reply-To: <CAPYw7P43rB=k1=6c8PS=+wyk1eYLmOwTcoGbWNJtAJsZQNZr0Q@mail.gmail.com>



On 6/13/23 11:01 PM, Paul B Mahol wrote:
> On Wed, Jun 14, 2023 at 7:37 AM Paul B Mahol <onemda@gmail.com> wrote:
> Also there is no reason to use int for elements in tables when max value
> can be lower.
> Current table reading/handling code should be completely rewritten to use
> get_vlc2().
> And tables split so length of codes use uint8_t type.


I will split the tables into two arrays and make the first array uint8_t.

I was looking over the get_vlc2() function, and I don't believe it will be
able to replace the current dtsuhd_common.c's get_bits_var.

The current dtsuhd_common function and a sample table parameter:

    static const int uhd_table[2][8] = {
            // TABLE_BITS                     TABLE_ADD
        { 4, 4, 4, 4, 8, 8, 16, 32 }, { 0, 0, 0, 0, 16, 16, 272, 65808 } };
    static int get_bits_var(GetBitContext *gb, const int uhd_table[2][8])
    {
        static const int bits_used[8] = { 1, 1, 1, 1, 2, 2, 3, 3 };
        int code = show_bits(gb, 3); /* value range is [0, 7] */

        skip_bits(gb, bits_used[code]);
        if (uhd_table[TABLE_BITS][code] == 0)
            return 0;
        return get_bits_long(gb, uhd_table[TABLE_BITS][code]) + uhd_table[TABLE_ADD][code];
    }


It peeks ahead 3 bits, and uses them to read the three 8 element tables: bits_used,
uhd_table[0], uhd_table[1].  Skips "bits_used" bits, reads "uhd_table[0]" bits and
adds to that value the value from "uhd_table[1]"

get_vlc2 uses the GET_VLC macro which goes like this:

    #define GET_VLC(code, name, gb, table, bits, max_depth)         \
        do {                                                        \
            int n, nb_bits;                                         \
            unsigned int index;                                     \
                                                                    \
            index = SHOW_UBITS(name, gb, bits);                     \
            code  = table[index].sym;                               \
            n     = table[index].len;                               \
                                                                    \
            if (max_depth > 1 && n < 0) {                           \
                ...
                nb_bits = -n;                                       \
                                                                    \
                index = SHOW_UBITS(name, gb, nb_bits) + code;       \
                code  = table[index].sym;                           \
                n     = table[index].len;                           \
            ...
            }                                                       \
            SKIP_BITS(name, gb, n);                                 \


The end result from this function is "code".  It needs to be the result of
reading "uhd_table[0][x]" bits added to the value from "uhd_table[1][x]".
But, that only way to get to that value would be in the last read of
    "index = SHOW_UBITS(name, gb, nb_bits) + code;"
And "index" is not returned from that macro.
Further, index has a maximum size of 32 bits, which is a problem for the next
line "code  = table[index].sym;".  That table would be 4Gigs, and we don't
even want the value from that table.

So that means we can't use the "if" block at all.

This means the best get_vlc2 could do is replace the "show_bits" and "skip_bits"
of the original dtsuhd get_bits_var function.  The last get_bits_long would
still be needed.

In that case, "table[index].len" would have to be from the table "bits_used"
and "table[index].sym would have to be from that table "uhd_table[0]".
get_vlc2() would return the bits to read for the call to get_bits_long.

But, when building the table using ff_init_vlc_from_lengths, there is this line
from that function in vlc.c:
    code += 1U << (32 - len);
    if (code > UINT32_MAX + 1ULL) {
        av_log(logctx, AV_LOG_ERROR, "Overdetermined VLC tree\n");

"len" comes from the an input table to that function "bits_used[8]" and that
table has duplicate entries.  Specifically several values of "1".  And that
quickly causes the "overdetermined" error.  Looking over the other functions
in vlc.c, those do not look as if they would work well with the dtsuhd_common
tables either.

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

  parent reply	other threads:[~2023-06-14 18:24 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-14 15:39 Roy Funderburk
2023-04-14 16:40 ` Hendrik Leppkes
2023-04-14 16:48   ` Roy Funderburk
2023-04-15 14:56 ` Michael Niedermayer
2023-04-15 20:04   ` [FFmpeg-devel] [PATCH v2] " Roy Funderburk
2023-04-16 19:55     ` Michael Niedermayer
2023-04-16 21:52       ` Roy Funderburk
2023-04-17  4:12       ` [FFmpeg-devel] [PATCH v3 1/2] " Roy Funderburk
2023-05-08 17:49         ` Roy Funderburk
2023-05-13  7:28           ` Paul B Mahol
2023-05-15 14:50             ` Roy Funderburk
2023-05-15 20:35               ` Michael Niedermayer
2023-05-15 21:14                 ` Roy Funderburk
2023-06-13 14:26                   ` Paul B Mahol
2023-06-13 17:43                     ` Roy Funderburk
2023-06-13 18:09                       ` Paul B Mahol
2023-06-13 18:20                         ` Roy Funderburk
2023-06-13 19:04                       ` Anton Khirnov
2023-04-17  4:13       ` [FFmpeg-devel] [PATCH v3 2/2] " Roy Funderburk
2023-06-13 18:32         ` Paul B Mahol
2023-04-15 20:20   ` [FFmpeg-devel] [PATCH] " Roy Funderburk
2023-06-13 18:35 ` Paul B Mahol
2023-06-14  0:00 ` Roy Funderburk
2023-06-14  5:37   ` Paul B Mahol
2023-06-14  6:01     ` Paul B Mahol
2023-06-14  6:06       ` Paul B Mahol
2023-06-14  6:11         ` Paul B Mahol
2023-06-14 18:24       ` Roy Funderburk [this message]
2023-06-14 20:01 ` Roy Funderburk
2023-06-15 15:46   ` Paul B Mahol
2023-06-15 18:44     ` Roy Funderburk
2023-06-18 12:18       ` Paul B Mahol
2023-06-20 17:05 ` Roy Funderburk
2023-08-17 21:47 ` Roy Funderburk
2023-08-17 22:31   ` Paul B Mahol
2023-08-17 22:51     ` Roy Funderburk
2024-01-16 21:02 ` Roy Funderburk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=443cbb24-1f60-d664-8fa2-cbb35906a51f@funderburk.us \
    --to=royffmpeg@funderburk.us \
    --cc=ffmpeg-devel@ffmpeg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
		ffmpegdev@gitmailbox.com
	public-inbox-index ffmpegdev

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git