[FFmpeg-devel] [RFC] Negative Bitrate Assertion Error

Michael Niedermayer michaelni
Sat Dec 18 03:40:29 CET 2010


On Fri, Dec 17, 2010 at 05:11:32PM -0800, David Czech wrote:
> Hello, I am trying to fix a crash (for Google
> Code-In<http://www.google-melange.com/gci/task/show/google/gci2010/videolan/t129169175566>)
> I found while fuzz testing ffmpeg: found
> here<https://roundup.ffmpeg.org/issue2426>.
> I have tested this crash on ubuntu's packaged ffmpeg and the latest version
> of ffmpeg from svn trunk.
> 
>  I am new to ffmpeg's source code, but I do have some theories and
> information about the bug. As seen in the backtrace, we have a call to
> av_rescale() from av_estimate_timings_from_bit_rate. The ic->bit_rate passed
> to av_rescale is negative which causes the assertion error later on.

> The question is, should rescale handle negative values

no


> or if bitrate isn't
> supposed to be negative, where should the bitrate value be validated?

Thats actually not so easy to awnser
There are many awnsers ...

One thing you might try is to find all code that checks bitrate for 0 or not 0
and change that to <=0 and >0
Iam not sure if this would fix the bug but at least it would make the code
more robust

Hint, you can find these quickly in
grep -C4 'if.*bit_rate' --color libavformat/*.c


> 
> By the way, I've noticed that av_rescale should call av_rescale_rnd, with
> the exact same arguments, but it doesn't seem like that is happening (?).
> 
> #4  0x08446e87 in av_rescale_rnd (a=549859968, b=1200000,
> c=-1875801792, rnd=AV_ROUND_ZERO) at libavutil/mathematics.c:79
> #5  0x084471ef in av_rescale (a=0, b=0, c=-4294967296) at
> libavutil/mathematics.c:130

Try to recompile with optimizations disabled
(theres a switch to configure or you could edit CFLAGS in config.mak)


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
            conveniently.
New school: Use the highest level language in which the latest supercomputer
            can solve the problem without the user falling asleep waiting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101218/f7c49e41/attachment.pgp>



More information about the ffmpeg-devel mailing list