On Thu, Mar 01, 2018 at 03:52:10AM +0200, Ivan Kalvachev wrote: > On 3/1/18, Michael Niedermayer <mich...@niedermayer.cc> wrote: > > On Wed, Feb 28, 2018 at 10:14:15PM +0200, Ivan Kalvachev wrote: > >> Replace two bit handling loops and internal conditional branch > >> with simple formula using few logical operations. > >> > >> The old function would generate wrong output > >> if the input does not fit into 15 bits. > >> > >> Fix this by using 64 bit math and put_bits64(). > >> This case should be quite rare, since the bug > >> has not asserted itself. > >> > >> --- > >> It's attempt for speed optimization, but in the > >> process it turned out it needs also bugfixing. > >> > >> I only tested the old case of the code, > >> to confirm i've implemented the correct function. > >> > >> Haven't done any benchmarks or run fate. > > > > fate fails: > > > > Well, the good news is that > it compiles and doesn't crash. > > The change of generated files is expected. > The old code would write up to 63 bits > with regular put_bits() that is limited to 31 bits. >
> Are av_assert2() enabled during fate runs? > (That's how put_bits() checks for bit length.) add --assert-level=2 if you want it checked > > > I'd like to know if my code is correct/incorrect > before attempting to changing fate checksums. the fate test looked like it did not decode the encoded data as half the checksums where gone instead of changed IIRC [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML.
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
