This repository has been archived by the owner. It is now read-only.

DTS timestamps #2071

Closed
mkver opened this Issue Aug 9, 2017 · 5 comments

Comments

2 participants
@mkver

mkver commented Aug 9, 2017

Hello,

I think I found something similar to #1864, but this time with DTS: If I remux a Matroska file with dts audio (not DTS-HD Master audio) that uses lacing (I actually only checked MKVToolNix' lacing, i.e. 8 DTS frames in one simpleblock; I didn't test other lacing sizes), simpleblocks and no default duration, then there will be a gap of one DTS frame between the first two laces; if using the --disable-lacing switch, the gap will appear after the seventh DTS frame (i.e. the timestamps are 0, 11, 21, 32, 43, 53, 64, 85).
I also tested DTS HD Master and could not reproduce it in this situation (not even if I use the option to reduce it to its core); it also doesn't happen if the input isn't laced or has a default duration. And it doesn't happen with elementary DTS input. I haven't checked TS-input. And actually all DTS versions I checked had six channels with 1509kb/s core.

Greetings
Andi

@mbunkus

This comment has been minimized.

Show comment
Hide comment
@mbunkus

mbunkus Aug 9, 2017

Owner

A sample file would be nice. Thanks.

Owner

mbunkus commented Aug 9, 2017

A sample file would be nice. Thanks.

@mkver

This comment has been minimized.

Show comment
Hide comment
@mkver

mkver Aug 9, 2017

As you wish: I have uploaded three files: DTS-HD.MA.mka which contains what its name promises; a DTS.Core.mka which has been produced by reducing the first file to its core and deleting the default duration in the header; and DTS.Core.Remuxed.mka which is the second file remuxed again.

mkver commented Aug 9, 2017

As you wish: I have uploaded three files: DTS-HD.MA.mka which contains what its name promises; a DTS.Core.mka which has been produced by reducing the first file to its core and deleting the default duration in the header; and DTS.Core.Remuxed.mka which is the second file remuxed again.

@mbunkus

This comment has been minimized.

Show comment
Hide comment
@mbunkus

mbunkus Aug 9, 2017

Owner

Thank you very much. I'll take a look at them soonish.

Owner

mbunkus commented Aug 9, 2017

Thank you very much. I'll take a look at them soonish.

@mkver

This comment has been minimized.

Show comment
Hide comment
@mkver

mkver Aug 13, 2017

The similarity between the solution of this and #1864 makes me wonder if there are other codecs where something like this could happen. Do you know one? If so just say it and I will test it. I don't know one (as you said, the reason for all this is that you have to check whether there is an extension for a core; and the only other codec I know of that uses such a method is wavpack in hybrid mode, but this is so different from the other codecs that I don't think it is susceptible to the same issue).
PS: I used an old build (that still had the ac-3 bug in it), deleted the default duration from an ac-3 track in Matroska and remuxed the file. The resulting file didn't have a gap. Is the reason for this difference that ac-3 and eac-3 use different CodecIDs in Matroska so that you do not need to look into the bitstream whereas you have to do this with DTS in Matroska (because e.g. the samplerate could be wrong because the sample rate in the header disregarded an extension)?

mkver commented Aug 13, 2017

The similarity between the solution of this and #1864 makes me wonder if there are other codecs where something like this could happen. Do you know one? If so just say it and I will test it. I don't know one (as you said, the reason for all this is that you have to check whether there is an extension for a core; and the only other codec I know of that uses such a method is wavpack in hybrid mode, but this is so different from the other codecs that I don't think it is susceptible to the same issue).
PS: I used an old build (that still had the ac-3 bug in it), deleted the default duration from an ac-3 track in Matroska and remuxed the file. The resulting file didn't have a gap. Is the reason for this difference that ac-3 and eac-3 use different CodecIDs in Matroska so that you do not need to look into the bitstream whereas you have to do this with DTS in Matroska (because e.g. the samplerate could be wrong because the sample rate in the header disregarded an extension)?

@mbunkus

This comment has been minimized.

Show comment
Hide comment
@mbunkus

mbunkus Aug 13, 2017

Owner

About codecs: no other audio codec should be affected. DTS and (E-)AC-3 are somewhat unique in that the extensions they use are not signaled in the main packet.

For video codecs such as h.264/AVC and h.265/HEVC have similar issues, but for them I've implemented position-aware timestamp handling right from the start — mostly because it was necessary right from the start, whereas both AC-3 and DTS were only extended with non-core packets long after the base format had been specified and implemented in mkvmerge.

I cannot answer the question in the second paragraph.

Owner

mbunkus commented Aug 13, 2017

About codecs: no other audio codec should be affected. DTS and (E-)AC-3 are somewhat unique in that the extensions they use are not signaled in the main packet.

For video codecs such as h.264/AVC and h.265/HEVC have similar issues, but for them I've implemented position-aware timestamp handling right from the start — mostly because it was necessary right from the start, whereas both AC-3 and DTS were only extended with non-core packets long after the base format had been specified and implemented in mkvmerge.

I cannot answer the question in the second paragraph.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.