[vlc-devel] [PATCH 9/9] omxil: Pass pts as timestamp on the ducati decoder
martin at martin.st
Wed Apr 4 15:23:10 CEST 2012
On Wed, 4 Apr 2012, Jean-Baptiste Kempf wrote:
> On Wed, Apr 04, 2012 at 03:18:00PM +0300, Martin Storsjö wrote :
>> This decoder reorders timestamps according to the frame reordering,
>> and thus should be given pts instead of dts. Other decoders don't
>> do this reordering and should be given dts.
>> Still to be investigated how android/stagefright handles this,
>> since it always seems pass pts, not dts, to decoders.
> I do not understand. I did not apply.
We pass only one timestamp to the omx decoder. If the content has
b-frames, the frames are reordered when decoding. Some decoders
(ducati/omap4) keep the timestamp along with the frame when reordering, so
that the output timestamps are reordered compared to what is input. Other
decoders (nexus one, galaxy s2) don't seem to do this, but outputs
timestamps in the same order as they're input.
Thus, if the decoder does timestamp reordering and we input pts, the
output is right, and conversely, if the decoder doesn't do any reordering
and we input dts (as we've done so far), the output is also right. If we
pass the wrong timestamps, the output timestamps are non-monotonic,
normally leading to not displaying every second picture, giving the
impression of half the framerate.
So this fixes the issue "why does it play back content with b-frames with
low frame rate" for the omap4.
Stagefright seems to only pass pts to the decoder - if we'd do the same,
we'd get the same visual effect on the other devices instead. Since I
don't have a setup for debugging the firmware of those devices ready at
the moment, I can't dig around to see what stagefright does in order to
fix that issue.
More information about the vlc-devel