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

[Uoti Urpala]

On Wed, 2006-08-09 at 11:32 -0700, Loren Merritt wrote:
> "breaks A-V sync" is avoidable, but involves adding to libavcodec's api, 
> hence the "implement reordering of timstamps". It's still independent of 

I think this would already work with "mplayer -correct-pts" without
changing the api. Would break sync with the old timing (which has wrong
sync if there's any delay, whether it's the "correct" delay for the
stream or not).

> container, I'm assuming that whatever timestamps the player will 
> eventually use to display with, are passed into lavc so that they can be 
> returned along with their correct frame.

-correct-pts kind of does that on the MPlayer side. Unless there are
input frames which will never get a corresponding output frame, you know
that the next reordered timestamp returned by the decoder would be the
smallest one that has been fed to it and hasn't been output yet, so you
can buffer timestamps on the player side and get the smallest one from
the buffer when the decoder returns a frame. Currently has_b_frames is
used as the maximum number of timestamps to buffer to avoid increasing
delay when there are input frames that won't be output.

> "visible jerk" means the codec will output frames out-of-order, when it's 
> supposed to sort them. There's no way the player can correct for that.

Yes if you only detect delay after a frame with a larger timestamp has
already been output then it's too late. I think I parsed "out of order
frame" differently when reading the first message (if the encoded frames
are IPB then P is the first one out of display order and B is the first
one not ordered by increasing timestamps).