[Ffmpeg-devel] Problems with output picture reordering in H.264 decoder
Wed Aug 9 20:32:17 CEST 2006
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.
More information about the ffmpeg-devel