[Ffmpeg-devel] Problems with output picture reordering in H.264 decoder

Michael Niedermayer michaelni
Wed Aug 9 21:31:55 CEST 2006


Hi

On Wed, Aug 09, 2006 at 08:53:42AM -0700, Loren Merritt wrote:
> On Wed, 9 Aug 2006, Santa Cruz, Diego (GE Indust, Security) wrote:
> 
> >I'm having problems with output picture reordering in H.264 decoder
> >(great piece of work BTW). I have a purely IPPPP stream, where the POC
> >increases by 4 with each frame.
> >
> >The first IDR is immediately decoded. However, upon decoding the first P
> >the decoder thinks that there is picture reordering required since the
> >POC increases by more than 2. The code in question is in h264.c,
> >decode_frame():
> >
> >08233  else if((out_of_order && pics-1 == s->avctx->has_b_frames && pics
> >< 15)
> >08234     || (s->low_delay &&
> >08235      ((!cross_idr && prev && out->poc > prev->poc + 2)
> >08236       || cur->pict_type == B_TYPE)))
> >
> >As far as I understand the H.264 spec the POC can increase by whatever
> >amount on two successive output pictures and this test seems too
> >restrictive. What is the reason for such a test? I would like to remove
> >it, but I am afraid I do not understand all the implications of it on
> >the H.264 decoder.
> 
> The reason for the test is that H.264 streams are not required to say how 
> much decoding delay they need. x264 does, but many other encoders don't.
> I see the following possible solutions:
> * Follow the spec and assume delay=16 if it's not specified. And then 
> implement reordering of timstamps, because this utterly breaks A-V sync.

furthermore that will cause some extra memory to be used for the 16frames
and depending on framesize and other things could cause some speedloss
due to the caches or impossibility of direct rendering

why not analyze the first few frames in av_find_stream_info() / the AVParser
to guess the delay? that seems to be the best solution especially if you
consider h264 -> foobar encoding for which correct timestamps will generally
be needed

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is




More information about the ffmpeg-devel mailing list