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

[Uoti Urpala]

On Wed, 2006-08-09 at 08:53 -0700, Loren Merritt wrote:
> 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.
> * Assume delay=1 if it's not specified. And break decoding if it needed 
> more. (This may be the most correct most of the time, but IIRC fails on 
> some stuff encoded by VSSH.)
> * Detect out-of-order frames. There will be a visible jerk the first time 
> it sees one, and this will break regression testing on many of the 
> official conformance clips.
> * Detect the frame before the out-of-order frame. No artifacts in the 
> normal case, but breaks if the stream does funny things with POC. (the 
> current implementation)

What kind of container timestamps are you assuming and what kind of
frame timing in the player? MPlayer wouldn't behave as you described,
neither with old timing nor with -correct-pts, at least if I understood
you correctly. By "detect the frame" do you mean the point at which the
decoder doesn't output a frame?