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.
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
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.
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.
But what wouldthe 30 bit timecode be good for if not for ordering the packets?
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.
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.