How to parse an M2TS file?

[hubblec4]

So the question is whether I even need to parse the durations if the duration can also be determined using the PTSs. Do you think that still makes sense?

Rocky (who used to work on set-top box backend HW/SW) told me there is a wrinkle involved. Since presentation times are evenly spaced, it is not essential to include a time stamp in every presentation unit. Instead, time stamps can be interpolated by the decoder, but they must not be more than 700 ms apart. Now, is timestamp interpolation something for you to worry about? He says he's never seen interpolation on bluray/UHD disks, nor on audio streams, although he has seen it on broadcast video streams (e.g., DVB, presumably for bandwidth saving). It's likely that in practice for bluray/UHD disks both ways are fine. But maybe you prefer to be safe and not sorry.

Very interesting, but at the same time very "disturbing" something like that. I'm a little unsure to what extent this should/must be taken into account. For now I'll "just" keep it in my head and then I'll have to see to what extent it needs to be taken into account.

Another complication is that if the video stream uses field pictures (unlikely for bluray/UHD) then the PTS difference would be halved. That would also complicate frame counting, as a frame would be made up of two field pictures. In practice it's not serious because it doesn't apply to audio and for video you can get the duration from the video frame rate. However, if you are needing to count frames you need to take this into account and not just count the PUSIs.

OK, good to know.
As far as I can tell, I don't really have to worry about the video stream. MTX does everything correctly when muxing. The subtitles should also be handled correctly, so I only have to worry about the audio and provide time stamp files for it.

BONUS TIP #2: If you want to avoid the sorting, which is only needed for video where pictures need to be re-ordered due to B pictures, you could parse the decode timestamp (DTS) instead of the PTS.

Also interesting. Is the DTS always present?
Since it's only about audio, it would be good to omit the sorting of the time stamps. However, Mosu told me that TrueHD Audio also has something similar to B and P frames, and could the time stamps be "swapped" here?

[Sherman]

You can have PTS without DTS but not vice versa. But it's irrelevant after what I say next.

You don't care about video. Great! That means all sorting can be ditched. Yes, TrueHD has major and minor frames but no re-ordering is involved, i.e., sorting is not needed.

Regarding PTS interpolation, again, Rocky has never seen that for audio in over 30 years of experience in these matters. As you suggest, we can just ignore it for now and I'll bet dollars to donuts it never comes back to haunt us. If in the unlikely event that it does we'll handle it then. Keep in mind that the DG tools have always assumed no interpolation for audio and it has never led to any trouble reports. If you do as good as DG stuff you will be doing well IMHO.

Since you don't care about video, as you have that covered, we can also ignore the frame/field coding distinction.

OK, so what's left to do?

1. You need to cover cases where the duration is not a single fixed value. I know only of EAC3 and (maybe) LPCM. I've already covered EAC3 in main4.cpp. The embedded AC3 will always be 32ms. Do you have LPCM under control or do you need me to do something?

2. You've asked for separate PTS reporting for the main and embedded streams. This affects EAC3 and TrueHD, which both can include embedded AC3. Surely I can do that.

I'll implement number 2 and then LPCM if needed.

Anything else?

[hubblec4]

You can have PTS without DTS but not vice versa. ....

You don't care about video. Great! That means all sorting can be ditched. Yes, TrueHD has major and minor frames but no re-ordering is involved, i.e., sorting is not needed.

OK, that is great. So I can remove the sorting option which should improve the speed a bit.

1. You need to cover cases where the duration is not a single fixed value. I know only of EAC3 and LPCM. I've already covered EAC3 in main4.cpp. The embedded AC3 will always be 32ms. Do you have LPCM under control or do you need me to do something?

For LPCM, I "determined" a value for the duration using MTX. The value is 200 FPS. Are there any other possible FPS values?

2. You've asked for separate PTS reporting for the main and embedded streams. This affects EAC3 and TrueHD, which both can include embedded AC3. Surely I can do that.

I'll implement number 2 and then LPCM if needed.

Anything else?

In principle, that should have been it.

[Sherman]

Regarding LPCM, I have not studied the relevant specs. For now let's stick with your empirical finding. We can come back to it if needed.

I'll get busy on number 2.

[hubblec4]

For now let's stick with your empirical finding. We can come back to it if needed.

Good idea.

I'll get busy on number 2.

Many thanks for all your work and time.

[Sherman]

You are most welcome. I have it coded and tested for EAC3/AC3 and just have to test all the audio formats. It will detect the audio format automatically.

[Sherman]

Please get main5.cpp. Everything is working according to my testing. Note that MAX_ACCESS_UNITS was increased to 10000000 to allow for the large number of TrueHD minor frames. Also, sorting was removed.

Lemme know if it is not OK or if there is anything else I can help you with.

[hubblec4]

This looks very good once again. Thanks very much.
A lot has changed there, but I'll figure it out.

[Sherman]

I'm sure you will, Mr hubblec4!

Ask if you don't grok how this derives from the PES and audio specs, or if you need copies of the specs.

[hubblec4]

Hi Sherman

Your source code is very easy to read because it is clearly structured. That makes it easy for me to understand everything.
I like the new way of skipping the PES_HEADER bytes.

OK, all the bits/bytes for the audio codecs mean nothing to me of course.
I have a question about the detection for TrueHD Audio.
It checks:
if (((b[4] << 24) | (b[5] << 16) | (b[6] << 8) | (b[7])) == 0xf8726fba)
But then there is no further check to see if it is an embedded AC3 stream. Is that still missing?

With E-AC3 the following is checked first:
else if ((((b[0] << 24) | (b[1] << 16) | (b[2] << 8) | (b[3])) & 0xffff0000) == 0x0b770000)
and then
if (((b[5] & 0xf8) == 0x80))
then a distinction is made between E-AC3 or embedded AC3.

[Sherman]

Thank you Mister hubblec4. You are very kind. You can come out and play with Alice and me any time!

For EAC3/AC3 both pusi's have the 0xb77 syncword and then you check the extra bit to distinguish them.

For TrueHD it's more accurate to say that THD and AC3 are merged (hence the utility thdmerge!) rather than embedded. So if a pusi doesn't pass the TrueHD test then it falls into the AC3 test and gets caught there.

If you have TrueHD and AC3 then it must be a merged AC3 (use has_truehd if needed). If you have an AC3 without TrueHD then it is a standalone AC3. Similarly for EAC3/AC3.

Glad you liked the idea of skipping the header, thereby avoiding scanning forward looking for syncwords.

The b[] offsets used are determined by the audio specs. You can trust me.

[hubblec4]

For TrueHD it's more accurate to say that THD and AC3 are merged (hence the utility thdmerge!) rather than embedded. So if a pusi doesn't pass the TrueHD test then it falls into the AC3 test and gets caught there.

Thank you very much for the explanation, now everything is clear.
By checking for TrueHD bytes, the AC3 stream is left out when the PTSs are parsed.

The b[] offsets used are determined by the audio specs. You can trust me.

I absolutely do that 100%.

[Sherman]

By checking for TrueHD bytes, the AC3 stream is left out when the PTSs are parsed.

Not quite. They are both reported separately, just as for EAC3/AC3.

[hubblec4]

Not quite. They are both reported separately, just as for EAC3/AC3.

You are right.
So far is all working now, maybe I can provide the new cE version this month.
Many many thanks to you for all your help.

[Sherman]

You are most welcome Mr hubblec4! It is my pleasure to be able to help you.