John Stebbins [[email protected]] wrote:
> On 03/02/2011 09:39 AM, Robin Stevens (SDS) wrote:
> > Hi,
> >
> > I have a number of VOB files which all feature the same strange behaviour.
> > After a certain period, the pts/dts timestamps on the packets reset to
> > almost zero.
> >
> > For example:
> >
> > 933, 375121777, 0000/01/01 00:00:37.512, 373200000, 1921777
> > 934, 375521777, 0000/01/01 00:00:37.552, 373600000, 1921777
> > 935, 375921777, 0000/01/01 00:00:37.592, 374000000, 1921777
> > 936, 4751111, 0000/01/01 00:00:00.475, 374400000, -369648889
> > 937, 5151111, 0000/01/01 00:00:00.515, 374800000, -369648889
> > 938, 5551111, 0000/01/01 00:00:00.555, 375200000, -369648889
> >
> > The columns are sample index, reported pts (from av_read_frame), formatted
> > pts, predicted pts, difference.
> >
> > The predicted pts is simply the sample index multiplied by 40ms (I'm
> > assuming 25fps video). Time basis is in 100ns ticks.
> >
> > The small difference (19221777) is due to the fact that I'm incorrectly
> > assuming a zero timestamp for the first frame.
> >
> > My best guess is that this stream was produced by concatenating two
> > streams, and failing to fix up the time stamps. Does that sound reasonable?
>
> mpeg-2 program streams (or transport streams) are not required to have
> continuous timestamps. There will be
> discontinuities. Normally, discontinuities in PS are detected by inspecting
> the SCR in the pack header. ISO 13818-1
> says there must be an SCR at least every 700ms. So if the difference between
> SCRs is >700ms it's a discontinuity.
>
Here is an excerpt from a more thorough analysis of the stream:
0x01272800 Program Pack { SCR = 0: 0: 37: 155 ( 3 343 989), MuxRate = 25 200
( 1 260 000) }
0x0127280E PES Packet { stream_id = 0xBD 0x80 (private_stream_1)}
0x0127290B PES Packet { stream_id = 0xBE (padding_stream)}
0x01273000 Program Pack { SCR = 0: 0: 0: 000 (0), MuxRate = 25 200 ( 1 260
000) }
0x0127300E System Header
0x01273026 PES Packet { stream_id = 0xBF (private_stream_2)}
0x01273400 PES Packet { stream_id = 0xBF 0x1 (private_stream_2)}
0x01273800 Program Pack { SCR = 0: 0: 0: 001 (146), MuxRate = 25 200 ( 1 260
000) }
0x0127380E PES Packet { stream_id = 0xE0 (video stream)}
0x01273824 Sequence Header
0x01273830 Sequence Extention
0x0127383C Sequence Display Extention
0x01273848 Group of Picture Header #78
time = 0:0:37:11
closed_gop = 1
broken_link = 0
0x01273850 Picture Header - I Frame #936
0x01273858 Picture Coding Extention
0x01273864 User Data {}
0x01274000 Program Pack { SCR = 0: 0: 0: 003 (292), MuxRate = 25 200 ( 1 260
000) }
0x0127400E PES Packet { stream_id = 0xE0 (video stream)}
The SCR also jumps back from 37:155 to 0:000.
I noticed that the GOP header #78 has a reasonable time value - perhaps other
muxers are using this value to resync the packets?
> > Is there any way I can use lavformat/lavutil/lavcodec to correct this
> > problem, *without* tracking the sample index myself? (I want to be able to
> > produce corrected timestamps following an arbitrary seek.)
>
> Somebody else can probably answer this better, as I'm not intimately familiar
> with libav* timestamp processing. But it
> looks like libavformat ignores pack headers. Given that, one way might be to
> look for large jumps in the dts. The
> problem with using dts however is that it is not required and is often
> missing. Using pts is an option, but pts can be
> out of order in the stream, so you would only want to look at this after
> decoding where libavcodec has re-ordered the
> frames for you. Whenever there is a substantial jump forward or backward,
> recompute an offset factor for all subsequent
> timestamps.
Thanks for your suggestion. Unfortunately I need to support true random access,
so looking for jumps is problematic. I can find a jump in the locality, but how
to define the locality? And what if the jump I found isn't the first one?
There's no sensible way that I can see of re-establishing the proper time
frame, unless I can access the GOP header.
Thanks,
Rob
Sira Defence & Security Ltd - Registered Office: York House, 74-82 Queen
Victoria Street, London, EC4N 4SJ - Registered in England and Wales - Company
number 05589861
CONFIDENTIALITY NOTICE:
This email message, and any accompanying attachments, is for the sole use of
the intended
recipient(s) and may contain information that is classed as Company-in
Confidence. If you are not the intended recipient, you are notified that any
use, dissemination, distribution or copying of this message and any
accompanying attachments, is prohibited.
If you received this email message in error, please notify us immediately and
erase all copies of this message and attachments.
Please note that Sira Defence & Security Ltd monitors incoming and outgoing
mail for compliance with its Email Policy. This will include scanning incoming
and outgoing emails to detect viruses and any spam mail.
_______________________________________________
libav-user mailing list
[email protected]
https://lists.mplayerhq.hu/mailman/listinfo/libav-user
