[FFmpeg-devel] [PATCH][RFC] Improve and fix put_vc2_ue_uint() function.
michael at niedermayer.cc
Thu Mar 1 04:11:28 EET 2018
On Thu, Mar 01, 2018 at 03:52:10AM +0200, Ivan Kalvachev wrote:
> On 3/1/18, Michael Niedermayer <michael at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: not available
More information about the ffmpeg-devel