Mpeg Stream timecode - what does it mean?

[stevz]

Hi

maybe this is offtopic for this forum but I still hope that someone does know and can help me out. I'm writing a demuxer for MTS container format to feed the essential h264 stream to the Intel Media SDK.

I seem to parse the packets correctly. At least I detect the sync bytes as expected and see reasonable values for the packet ID's and the continuity counters.

However, the 4 bytes timecode that precedes the sync byte provides some weird values that I cannot make sense of. I was expecting something like one byte each for hh:mm:ss:frame but that already gives me timecodes with mm or even hh values which are much greater than the duration of the whole MTS clip.

My searches so far did not reveal any resource that explains the timecode format and usage in the MTS but I was expecting this to help me with random access specific frames or time positions in the middle of my stream to skip decoding the whole stream if I only want to play the stream from somewhere in the middle.

regards

[Markus_Pingel]

The MTS container is like the transport stream defined in ISO/IEC 13818-1 with an additional header of 4 bytes:

The first 2 bit valueis thecopy permisson indicator and can be ignored for what you want to achieve.
The next 30 bit integeris the arrival time stamp (with a resolution of 27 MHz).

Hope that helps

[Nina_K_Intel]

Great thanks for your help, Markus!

[stevz]

Hi Markus

thanks a lot. I happened tojust stumble across this 2 bit catch in some BluRay spec when you provided the answer here :)

Now the values I extract from the stream start to make some sense. Maybe you can kindly feed me some information what this timecode should tell me. I was expecting some kind of time relative to some kind ofstart value (such as provided from the camcorder e.g.) that keeps on increasing for packets with the same PID.

But that is either not the case or I am still parsing something wrong here. The following values below are an example of what I extract so far. The first value is the PID and the second is the 30 bit timecode which is relative to the timecode of the first packet I got from the stream. The pattern is about the same for all different PIDs. The timecode increases and then there is a jump back to a smaller timecode which then increases again.

4608: 1546963456

4608: 1547363328

4608: 1547763200

4608: 1548163072

4608: 1548562944

4608: 1548962816

4608: 1549362688

4608: 1549762560

4608: 1550162432

4608: 1550562304

4608: 1550962176

4608: 615741440

4608: 616141312

4608: 616541184

4608: 616941056

4608: 617340928

4608: 617740800

4608: 618140672

4608: 618540544

4608: 618940416

I hope I don't sound too stupid here but I can't see how to interpret these values for random access to jump my decoder close to ... say an arbitrary frame n to start decoding from there.

regards,
Stefan

[stevz]

Hm ... rethinking this the resolution of a 27MHz counter with 30 bits would not allow for a continouus timing of the stream. So I think I have to look into the adaption field to find random access points?

But what wouldthe 30 bit timecode be good for if not for ordering the packets?

[Markus_Pingel]

The values look strange and are always multiples of 0x100.Are there correctly converted from Motorolato Intel format?
The value is the time when the packet issent to a theoretical player buffer. Speaking from experience I would suggest to just ignore it. It won't help you much to find the video frame.
Just look for transport packets with payload start indicator and collect the payload (a PES packet) from there.
You have to find the random access points (I frames with a sequence header or SPS) yourself or you use the clipinfo file if it is available.

[stevz]

Yeah ... meanwhile it looks like ignoring the timecode is what most stream analyzers do :)

Now I decided to do likewise and browse for the packets first to analyze my streams for PAT, PMT, and ES. I got distracted by the timecode and misunderstood that as information that would help me with the random access.

Thanks for your input which helped me to get a better idea of the mpeg steams.

regards,
Stefan