[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