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

Kalileo kalileo at universalx.net
Fri May 4 13:37:06 CEST 2012


On May 4, 2012, at 00:16 , jettoblack wrote:

> 
> 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 its?  

 in a stream with h264, yes.

> 
> 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
> 

That's how I do it, and it works for me. Wait for the first I-frame and start feeding the video frames to the decoder with this first I-frame.

I remember that I've seen video frames with a lower pts even after such an I-frame, however I ignore that pts, but not such a frame. After the first I-Frame they all go to the decoder.

The pts / dts of that first I-frame is what you sync with the dts / pts of the first audio or whatever frame you take and sync from there. 


More information about the Libav-user mailing list