Hello, Le ven. 8 sept. 2023 à 00:39, Andreas Rheinhardt <andreas.rheinha...@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 _______________________________________________ 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".