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

[Loren Merritt]

On Wed, 9 Aug 2006, Uoti Urpala wrote:

> On Wed, 2006-08-09 at 10:14 -0700, Loren Merritt wrote:
>> On Wed, 9 Aug 2006, Uoti Urpala wrote:
>>> 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?
>>
>> I assume nothing about the container. This algorithm runs entirely inside
>> libavcodec, using the h264's own pseudo-timestamps, "POC". If the current
>
> I meant assumptions in the post I replied to. You phrased the results of
> the different choices in terms of "breaks A-V sync", "There will be a
> visible jerk", "No artifacts in the normal case". Those sounds like
> they're player behaviors (certainly at least the first one is, "visible
> jerk" might have causes the player could or could not avoid).

"breaks A-V sync" is avoidable, but involves adding to libavcodec's api, 
hence the "implement reordering of timstamps". It's still independent of 
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.
"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.

--Loren Merritt