On Thu, Jun 15, 2023 at 8:45 PM Roy Funderburk <royffm...@funderburk.us>
wrote:
>
>
> On 6/15/23 8:46 AM, Paul B Mahol wrote:
> > get_vlc2 can be made for get_bits_var(), first table bits (that are still
> > int and not uint8_t), the code that picks table index from which to take
> > bits.
> >
> > It is also possible to make it take both first index and rest of it and
> > build bigger tables but that is very very advanced step for new
> > contributors.
> >
> > Use INIT_VLC_SPARSE_STATIC, there are myriad examples in libavcodec, one
> of
> > them being imm4 decoder.
> >
>
> I will change that table bits array to uint8_t.
>
> I encountered an issue when trying to set up the VLC table with
> INIT_VLC_SPARSE_STATIC.
>
> The current get_bits_var:
>
> static int get_bits_var(GetBitContext *gb, const VarBits *var_bits)
> {
> static const uint8_t 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 (var_bits->bits[code] == 0)
> return 0;
> return get_bits_long(gb, var_bits->bits[code]) +
> var_bits->add[code];
> }
>
> Changed to use get_vlc2 would be:
>
> static int get_bits_var(GetBitContext *gb, const VarBits *var_bits)
> {
> int code = get_vlc2(&gb, vlc.table, 3, 1);
> if (var_bits->bits[code] == 0)
> return 0;
> return get_bits_long(gb, var_bits->bits[code]) +
> var_bits->add[code];
> }
>
> The "vlc.table" that INIT_VLC_SPARSE_STATIC needs to output is:
>
> len: 1, 1, 1, 1, 2, 2, 3, 3
> sym: 4, 4, 4, 4, 8, 8, 16, 32
>
> INIT_VLC_SPARSE_STATIC would get the same len and sym and this code table
> as input:
> code: 0, 1, 2, 3, 4, 5, 6, 7
>
> INIT_VLC_SPARSE_STATIC rejects the "len" and "code" because the code
> of "2" will not fit into one bit. Regardless of the fact that the desired
> output table is not a valid table according to VLC functions, that invalid
> table is what is needed.
>
> This goes back to how get_bits_var decodes the bit context.
> get_bits_var looks at three bits to get an index in the range of 0-7.
> But it may not skip all of those bits. One or two of those bits may also
> be
> read by the final get_bits_long.
>
> code = show_bits(gb, 3);
> skip_bits(gb, bits_used[code]);
> get_bits_long(gb,...);
>
> The VLC functions to construct tables have validation in place that
> prevents
> the construction of the table needed for get_vlc2() to work with
> get_bits_var.
>
> So the only way I can find to use get_vlc2() is to not use any of the vlc.h
> initialization functions, and instead hard-code the tables to be used by
> get_vlc2() like this:
>
> VLCElem table[8] = { {4,1}, {4,1}, {4,1}, {4,1}, {8,2}, {8,2}, {16,3},
> {32,3} };
>
> Before I do that, I wanted to verify this would be acceptable. Would
> this be a use of get_vlc2() that could lead to issues in the future
> if the GET_VLC macro changed so that it would not skip fewer bits than the
> code length?
>
> What is your opinion on this?
>
Well, just keep that part as is currently, until someone else cleans it up.
Can probing in new demuxer be smarter than just decreasing score of another
demuxer?
>
> Thanks,
> -Roy
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
