'ctts' atom (quicktime / mp4)

[ApPojken]

Hi all,

I am writing a mp4/mov rewrapper (and possibly mux functionality). I got everything working but the 'ctts' atom (Composition Time to Sample Box). Currently, I am not inserting it which means that the playback of my rewapped 12-gop mpeg2 video is very stuttery.

I have been Googling for a couple of days but I can now confess that I am stuck. Can anyone explain how exactly this one works and how I should be inserting it? (Explain like I was a baby) ...or point to somewhere where I can read in fine detail.

The mp4 spec states "This box provides the offset between decoding time and composition time". Got it but the next line I don't get: "Since decoding time must be less
than the composition time, the offsets are expressed as unsigned numbers such that CT(n) = DT(n) +
CTTS(n) where CTTS(n) is the (uncompressed) table entry for sample n."

The ctts table in the mp4 looks like this:
Sample Count = 1, Offset = 3000
Sample Count = 2, Offset = 0
...repeated a lot of times

The ctts table in the Quicktime looks like this when properly rewrapped:
Sample Count = 1, Offset = 200
Sample Count = 2, Offset = -100
...repeated the same amount of times..

Why are they so different from eachother? The video content is identical in the mdat atom. ...and how can I translate one to the other when rewrapping? :confused:

[mediator]

The ISO/MPEG-4 container allows only for unsigned composition offset values (as can be seen in the spec). If you have frame reordering (classical b-frame scheme) this results in the fact that the CT of the first frame cannot be aligned with time zero (with edit lists it is still possible to align the start of the final presentation with zero, but this is another level of complexity, and cannot be assumed to be commonly supported by splitters).

QuickTime format designers apparantly wanted to be able to express a CT=0 of first sample, even if frame reordering/b-frames is used. The most straightforward way to achieve this was to break with ISO MPEG-4 and allow negative composition offset values. This means a reader/parser which is strictly ISO-MPEG-4 compliant would not support quicktime ctts tables.

I hope this helps. Good luck with your rewrapper!

[Ritsuka]

The version 1 of the ctts atom allows signed values too.
So a strictly iso file format parser would need to be updated to keep up with the specifications.

I guess if you have values so different you are doing something else wrong, but without knowing how your application works I don't know.

[mediator]

ISO 14496-12:2008 says "sample_offset is a non-negative integer [...]". A version 1 of ctts seems not to be defined there.

@Ritsuka: can you please give a reference for ctts version 1? Must be quite new...

[ApPojken]

Thanks for your input.

I got some ideas and worked out why the values are so different from eachother. (To clarify, I am using a third party rewrapper to get a properly wrapped mov 'ctts' atom for referencing).

The mp4's timescale is 10 times larger than the one in the mov file (25000 vs. 2500). Since I am not changing the timescale when I am rewrapping, I should be inserting the following to the ctts table:

Sample Count = 1, Offset = 2000
Sample Count = 2, Offset = -1000
..etc

I am however still not clear on how I work out the 2000 value. Why wouldn't it start on 0 in the mov file? The edit list table starts at 0 and has the same duration as the 'mvhd' duration.

[Ritsuka]

@Mediator: http://standards.iso.org/ittf/PubliclyAvailableStandards/c052356_ISO_IEC_14496-12_2008_Amd_1_2009.zip

@ApPojken The 2000 value is just the 3000 value of the mp4 minus the delay of the first frame caused by b-frames.

[ApPojken]

Thanks, Ritsuka. That brings better clarity.

[roozhou]

You can use DTS compression to solve this issue. If CTTS(n) is negative, decrease DT(n) until CTTS(n) is non-negative.