Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

MPEG-2 Demultiplexer timestamps

12 views
Skip to first unread message

l33tpr0gr4m3r

unread,
Oct 28, 2009, 10:29:40 AM10/28/09
to
I am demultiplexing a live ATSC transport stream with the MPEG-2
demultiplexer. Looking at timestamps on the IMediaSamples coming from
the video out pin, they are out of order. What's up with that? I
don't think the MPEG-2 decoders use these timestamps, but I am trying
to write these samples to an ASF file and am wondering if I need to
reorder these samples? Or maybe replace the timestamps with new ones?

Geraint Davies

unread,
Oct 29, 2009, 8:45:54 AM10/29/09
to

Mpeg video uses bidirectional prediction (see
http://en.wikipedia.org/wiki/MPEG-1#Frame.2Fpicture.2Fblock_types).

This requires the frames to be decoded in a different order to the
presentation order. Briefly, if the B frames depend on the reference
frames at the start and the end of the sequence, you need to decode
both the start and the end of the sequence before you can decode the B
frames in the middle, so they are stored and delivered in decoding
order like that.

The mpeg TS contains both presentation time and decode time. You will
find that the decode time is in sequential order, but the presentation
time is not. DirectShow passes the presentation time (converted to a
directshow timestamp) and in fact most decoders will use this
timestamp -- although they will extrapolate between timestamps where
necessary, so a single timestamp per GOP would be sufficient.

G

l33tpr0gr4m3r

unread,
Oct 29, 2009, 12:36:36 PM10/29/09
to

>
>This requires the frames to be decoded in a different order to the
>presentation order. Briefly, if the B frames depend on the reference
>frames at the start and the end of the sequence, you need to decode
>both the start and the end of the sequence before you can decode the B
>frames in the middle, so they are stored and delivered in decoding
>order like that.
>
>The mpeg TS contains both presentation time and decode time. You will
>find that the decode time is in sequential order, but the presentation
>time is not. DirectShow passes the presentation time (converted to a
>directshow timestamp) and in fact most decoders will use this
>timestamp -- although they will extrapolate between timestamps where
>necessary, so a single timestamp per GOP would be sufficient.
>
>G

Thanks, I understand now.

0 new messages