VOB timestamp reset

[extra]

I have a VOB file:
http://www.dvdloc8.com/distributorclip.php?distributorid=15&clipid=2

The present time stamp increases but will reset to zero and start over again near the end of the file. Does anyone know why it works like this? Is this the reason many player could not recognize correctly the play duration of a vob file? How are decoders/demuxers supposed to deal with this?

Thanks for any help!

[Guest]

It's not that unusual because the leadin is often encoded separately from the main movie, etc.

[extra]

In this case shouldn't the leadin and main movie have two different Stream ID? In this file, the Stream ID for video is the same, always 0xE0... Should the demuxer regard them as two different streams?

[Guest]

In this case shouldn't the leadin and main movie have two different Stream ID? I'm not aware of any spec that asserts such a thing.

Should the demuxer regard them as two different streams? Not at the elementary video syntax level. Aren't they differentiated in the DVD structure?

[extra]

I'm not aware of any spec that asserts such a thing.

But if we stick to the spec of MPEG2 program stream, the last few packets should be displayed at the very beginning of the program, causing duplicate timestamps... I must be missing something, like a new time reference...

Not at the elementary video syntax level. Aren't they differentiated in the DVD structure?

VOB file is 100% MPEG2 program stream compatible... so I guess it should be able to play correctly even without the DVD structure. Am I wrong?

[Guest]

But if we stick to the spec of MPEG2 program stream, the last few packets should be displayed at the very beginning of the program, causing duplicate timestamps... I must be missing something, like a new time reference... I suppose you are missing the SCR, which is the timebase of the stream.

Don't forget that the timestamps (SCR, PTS, DTS) are a finite size in bits, so they can wrap back to zero in normal operation.

[extra]

I suppose you are missing the SCR, which is the timebase of the stream.

Don't forget that the timestamps (SCR, PTS, DTS) are a finite size in bits, so they can wrap back to zero in normal operation.

Thank you for the tip. I check the spec again.

"SCR indicates the intended time of arrival of the byte containing the last bit of the system_clock_reference_base at the input of the program target decoder". So it's not the reference time we are looking for.

The wrap back point is about 26 hours and could not be possible in this case.

God, why VOB is implemented like this?

[Guest]

SCR is indeed the timebase of the stream for program streams (VOB is a program stream). The equivalent for transport streams is PCR. You can use the Log Timestamps function of DGIndex to see that the SCR resets along with the PTS.

A decoder should align a local clock with the stream's SCR. Then, an access unit is displayed when it's PTS (possibly interpolated) matches the local clock.

My point about the wrap-around is that it *can* occur. Also, in broadcast environments, the timebase and associated timestamps can all shift when a new stream is sent (e.g., new program, cut to commercial, etc.) This is called a discontinuity and decoders must not be designed to assume that there are no discontinuities.

Using the starting and ending PTS to determine a stream duration is a heuristic that is foiled by any discontinuities.

[extra]

SCR is indeed the timebase of the stream for program streams (VOB is a program stream). The equivalent for transport streams is PCR. You can use the Log Timestamps function of DGIndex to see that the SCR resets along with the PTS.

A decoder should align a local clock with the stream's SCR. Then, an access unit is displayed when it's PTS (possibly interpolated) matches the local clock.

My point about the wrap-around is that it *can* occur. Also, in broadcast environments, the timebase and associated timestamps can all shift when a new stream is sent (e.g., new program, cut to commercial, etc.) This is called a discontinuity and decoders must not be designed to assume that there are no discontinuities.

Using the starting and ending PTS to determine a stream duration is a heuristic that is foiled by any discontinuities.

Thank you so much neuron2. I think I understand how it works now.

So in the case of discontinuities, the calculation of present and decoding time of frames, as well as that of the total duration, should take into account the differences of the SCR.

But in a software implementation, how to calibrate the decoder time clock? using the mux rate and byte counts? I need to dig into the spec again...:thanks: