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

Michael Niedermayer michaelni
Fri Dec 25 22:24:43 CET 2009


On Fri, Dec 25, 2009 at 02:56:57PM -0500, Jason Garrett-Glaser wrote:
> x264 will soon be committing Periodic Intra Refresh, an extremely
> powerful feature for low-latency, high-resilience streaming.  This
> will involve using SEI Recovery Points as seek points in H.264 video
> files.  This already works partially with container formats like MKV
> and MP4 that flag keyframes.  However, there is the following, massive
> gotcha:

I see no reason why it would work better with mp4/mkv than others.
But i might be unaware of some changes ...


> 
> The standard specifies that, upon seeking to an SEI Recovery Point,
> that the decoder shall not display the video until recovery_frames_cnt
> frames have been decoded.
> 
> This is relied upon heavily in Periodic Intra Refresh.
> 
> How should this be implemented in ffmpeg?  Should the decoder return 0
> for every frame decoded after seeking until recovery_frames_cnt is
> reached?

with the current API
it should set got_picture_ptr=0 and return the numer of bytes consumed,
which is what you meant i suspect

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 ...)


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

Democracy is the form of government in which you can choose your dictator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20091225/4d77f907/attachment.pgp>



More information about the ffmpeg-devel mailing list