[FFmpeg-devel] [libav-devel] [QUESTION] Proper handling and reporting of decoding errors

Ronald S. Bultje rsbultje at gmail.com
Fri Jun 10 02:49:51 CEST 2011

Hi Maxim,

I see Michael already answered, so just to add on to that:

On Thu, Jun 9, 2011 at 6:36 PM, Maxim <max_pole at gmx.de> wrote:
> case 1: my decoder encounters a broken P-frame. That usually means that
> all following frames until the next key one will be broken as well. The
> proper reaction would be to wait for the key frame.
> What kind of signal does the calling library expect in this case? Error
> code/empty frame?
> Should I introduce some kind "need_resync" flag in the decoder and skip
> broken frames internally or is there any possibility to report broken
> frames to the caller?

There's error_resilience.c, but that's specific to
MpegEncContext/mpegvideo.c-based codecs, and has quite some
codec-specific code. You can look at that for inspiration but I feel
that it needs to be partially rewritten to be more widely useful.

If you don't want complete error_resilience, maybe skipping is fine,
yes. Different codecs in ffmpeg do different things, h264/mpeg do
error resilience, vp3 returns a green frame (since i-blocks will give
at least a partially normal image in subsequent p-frames), vp8 holds
on until the next keyframe (this has to do with arithmetic context
probabilities). It all depends on your codec, basically.

> case 2: indeo codecs uses sometimes so-called "sync"-frames. The frame
> data just contain a short header (16 bytes) indicating that nothing has
> changed. I guess that feature or hack was introduced in order to enable
> variable frame rate which isn't otherwise provided in the AVI container.
> Returning previous frame and reporting number of consumed bytes should
> be fine in that case, shouldn't it?
> Would it introduce duplicated frames?

Set *data_size=0 before returning and it'll be like a skip-frame.
Sounds a lot like VC-1's P-skip frames to me, which are basically the
same. If you want to duplicate frames, use
codeccontext->reget_buffer(), which returns a copy of the last
returned frame, so you can re-return it, or just memcpy the old frame
into a new buffer.


More information about the ffmpeg-devel mailing list