[Libav-user] Frame order from TS demux - mpeg2video vs h264

jettoblack jettoblack at gmail.com
Thu May 3 19:16:42 CEST 2012


Kalileo wrote
> 
> On Apr 30, 2012, at 23:53 , jettoblack wrote:
> 
>> On Mon, Apr 30, 2012 at 2:51 AM, Kalileo [via libav-users] <
>> ml-node+s943685n4597541h88 at .nabble> wrote:
>> 
>>> 
>>> The decoder gives you the (decoded) pictures in the correct order.
>>> 
>>> 
>> That's what I expected, and it does for MPEG-2 codec video, but not for
>> H.264 codec within a MPEG-2 transport stream.
> 
> It does. Otherwise there would be no way to display h264 video correctly
> ;)
> 
> As i said, and as also Andrey Utkin pointed out, the correct order for
> display is in the pts value, and after decoding (not after demuxing) the
> pictures/frames should be in pts order, ready for display.
> 
> 

Thanks Kalileo, I think I'm getting it now. :)

So, related question, I want to figure out what is the starting pts of the
stream (lowest pts).  Is this info available from the demuxer by the time of
demuxing the first picture packet, or do I have to wait until I receive some
number of packets and look for the one with the lowest pts?

I have seen some files where the first packet is an I frame, and the next is
a B frame that precedes the I frame (BBIBBP...), e.g.:
pkt 0: I frame dts 126000 pts 135009
pkt 1: B frame dts 129003 pts 129003
pkt 2: B frame dts 132006 pts 132006
pkt 3: P frame dts 135009 pts 144018
...

I suppose at the time of demuxing packet 0, there is no way to know yet that
the next packet will have a lower pts?  

Would a workaround be to discard any frames with a pts lower than the first
I frame?

I really appreciate the help, thanks again!
Jason


--
View this message in context: http://libav-users.943685.n4.nabble.com/Frame-order-from-TS-demux-mpeg2video-vs-h264-tp4597204p4606589.html
Sent from the libav-users mailing list archive at Nabble.com.


More information about the Libav-user mailing list