[FFmpeg-devel] [PATCH 1/2] Expose and start using skip_remaining

[Christophe Gisquet]

Hello,

Le ven. 8 sept. 2023 à 00:39, Andreas Rheinhardt
<andreas.rheinhardt at outlook.com> a écrit :
> This is problematic, because you seem to think that bits_peek(bc, bits)
> ensures that there are at least `bits` available in the cache;

read_vlc* also makes that assumption? Anyway, I'd put that behaviour
(of checking) under (!)UNCHECKED_BITSTREAM_READER,
and effectively this is about corrupt/unsupported bitstreams. Maybe
some parts of ffmpeg have been wrong for 15 years, and that should be
done instead of expecting the reader desyncs and/or checks at the
upper level of the loop the exhaustion of the bitstream.

> https://github.com/mkver/FFmpeg/commit/fba57506a9cf6be2f4aa5eeee7b10d54729fd92a
> for a way that fixes this.

I can only notice now I neither have the time, nor am enough
interested to embark in that scrutiny of current code. I'm OK to wait
for the ffmpeg project to have decided on a solution for the specifics
you are discussing.

> the assumption that the
> combined amount of bits consumed in any get_vlc2/GET_RL_VLC/BITS_RL_VLC
> call can't exceed 32. Is this assumption actually still true now that we
> have multi-vlc stuff?

It doesn't change anything there: it operates as the first stage/level
of any get_vlc, only it can output more than 1 symbol.

> https://github.com/mkver/FFmpeg/commit/9b5a977957968c0718dea55a5b15f060ef6201dc
> and
> https://github.com/mkver/FFmpeg/commits/aligned32_le_bitstream_reader
> are probably also of interest to you.

They probably would, had I the time. My goal was really to prevent the
prores and multi-symbol from bitrotting too much, but I wasn't
expecting these roadblocks.

I'm sorry to say I'm dropping the patch series.
-- 
Christophe