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. > 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. > > 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? > I can't really comment on what vlc does. But it's possible that different demuxers are being used in each case.
_______________________________________________ libav-user mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/libav-user
