[vlc-devel] [PATCH 9/9] omxil: Pass pts as timestamp on the ducati decoder

Martin Storsjö 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.

// Martin


More information about the vlc-devel mailing list