[FFmpeg-devel] [RFC] H.264: Supporting Recovery Point SEIs

Reimar Döffinger Reimar.Doeffinger
Sat Dec 26 10:19:08 CET 2009

On Fri, Dec 25, 2009 at 11:28:37PM -0500, Jason Garrett-Glaser wrote:
> On Fri, Dec 25, 2009 at 4:24 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > But there might be a more flexible and powerful solution.
> > Add a int flags to FF_COMMON_FRAME (thats AVFrame)
> > then add a AVFRAME_FLAG_DO_NOT_DISPLAY and set that for such frames.
> > That way an application can for debuging or otherwise display such frames
> > at the users request. These flags would also be extreemly usefull to
> > inform the user application if there where concealed decoding errors in a
> > frame (a thing some people requested ...)

I would prefer that as well. However I am not sure if the name is good,
be better?

> On a related note, how should we make ffmpeg not print errors for the
> frames consumed before display?  These will have tons of "error
> concealment" due to missing reference frames, but inherently those
> errors will be gone by the time one reaches the end of the
> recovery_frame_cnt period (well, as long as exact_match_flag == 1).
> It seems like bad form to spam the user with errors despite the fact
> that they are a for-sure part of the decoding process that will always
> happen in this case.

Well, I think you can't know for sure whether these problems happen
"normally" or because the file is indeed broken.
Of course you could have a flag in the codec context that indicates
you are searching for a " key frame" and disable the messages, but that
would need to change a lot of code I think.
Alternatively the av_log wrapper function could just check if we are
still searching for a "key frame" and not print errors from that context
However to make that not discard errors from the key frame itself we'd
probably still need such a flag that the codec disables upon finding it.

More information about the ffmpeg-devel mailing list