Hi Maxim, I see Michael already answered, so just to add on to that:
On Thu, Jun 9, 2011 at 6:36 PM, Maxim <[email protected]> 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. Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
