[FFmpeg-devel] [PATCH] Fix floating point exception computing duration when no time-base is set

[Art Clarke]

On Mon, Sep 14, 2009 at 6:32 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> what is the reason that he did not set a time_base as well?
>

Because our user screwed up in their API usage, and was using raw PCM
data .  They didn't set the AVFormatContext->audio_codec_id equivalent
in the Xuggler API and they didn't call the av_find_stream_info
equivalent, but they did set the the AVCodecContext->sample rate to a
non-zero value.  They then attempted to read a packet.  Since
AVCodecContext->sample_rate was non-null, libavformat decided to try
calculating duration of that packet (it otherwise wouldn't), but since
the user hadn't set a time base that av_read_frame call crashed their
entire Java virtual machine.  Shame on them.

That said, the result ends up being a core-dump which our Java library
cannot recover from (Java doesn't behave well with core-dumps).  We
try to write our API so that most programmer errors can be detected
and have an error thrown which doesn't crash the entire process.  We
do this because for many of our users they are running tens or
hundreds of threads with different encoder/decoders inside on Java VM,
and we want bad actors to not spoil the show for everyone.  But this
one is tricky to just work around in our library since we don't know
what type of packet is about to be read by av_read_frame.

The only other work around I thought of was in our code prior to each
call of av_read_frame, iterate through all current
AVFormatContext->streams and check for invalid time-bases, and then
throw an error if AVCodecContext->sample_rate > 0 but
AVStream->time_base is invalid.   But this puts a bigger performance
penalty on our "well behaving" users than the two integer check
approach I submitted.  Plus the patch I submitted allows users to
detect a problem has occurred and correct (e.g. if they read an audio
packet, but duration is 0, they know that something went wrong),
whereas the current code doesn't let people writing libraries using
libavformat to recover from this.

But I understand that libavformat has different goals than we do (i.e.
libavformat leaves the sharp edges to prioritize performance, while we
try to slightly blunt the sharp edges to protect our developers from
themselves).  I've applied this patch to our patched version of FFmpeg
(http://code.google.com/p/xuggle-ffmpeg/) but I'll stop pushing it for
inclusion in mainline.

- Art


-- 
http://www.xuggle.com/
xu?ggle (z?' gl) v. To freely encode, decode, and experience audio and video.

Use Xuggle to get the power of FFmpeg in Java.