[FFmpeg-devel] DVD (MPEG2 Program Stream) with resetting DTS/PTS & SCR

[Robin Stevens SDS]

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?



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



Note: When these files are played in something like VLC, the timestamps are wrong (VLC's time indication stops incrementing past the 37s point in this example.) However, if I use VLC to load the VIDEO_TS folder, the time indication is correct. This is probably the wrong mailing list, but: how is VLC determining the correct time?



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?


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