On 03/02/2011 11:01 AM, Robin Stevens (SDS) wrote: > 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? The timecode in the GOP isn't used for decoding, so is not technically required to be accurate. It is often unset or inaccurate.
>>> 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. mpeg TS and PS are not designed for random access. Formats like DVD and BD layer more structure (an index of timestamps to sector or packet) on top of the raw stream in order to achieve this. There really is no way to do random access without creating such an index in PS or TS. Short of creating an index, the best you can do is create heuristics that could combine several methods like using GOP timecodes if they "look" right, PTS if it "looks" like there have been no discontinuities or map byte location in the file to an approximate timestamp (based on an average bits per frame calculation). _______________________________________________ libav-user mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/libav-user
