[m4v -> mkv] remux questions

[PluueeR]

I'm having sync issues when playing m4v files (encoded with Handbrake) on my media player. It seems the poor thing doesn't know how to handle these files properly (chapter and subtitles don't work either).

I decided to give mkv a try (got a huge collection though, so even remuxing will be a though job) and it seems the mkv's are handled correctly by the media player. I do have a couple of questions:

1. On some files I get this warning when remuxing using mkvtoolnix:

Warning: '/Users/joran/Desktop/Penoza (2010) S01E01.m4v' track 1: The AVC video track is missing the 'CTTS' atom for frame timecode offsets. However, AVC/h.264 allows frames to have more than the traditional one (for P frames) or two (for B frames) references to other frames. The timecodes for such frames will be out-of-order, and the 'CTTS' atom is needed for getting the timecodes right. As it is missing the timecodes for this track might be wrong. You should watch the resulting file and make sure that it looks like you expected it to.

They file in question was converted using an other preset than that I use today (today's files don't show this warning). I believe the old ones (with the warning) don't have b-frames and the newer ones do. I do I check for b-frames?

2. If the source hasn't got the CTTS atom set, it shouldn't be a problem for the destination right?

3. Remuxing doesn't touch streams, am I right? If thing go bad, I'll always have my streams? Can I recreate a file from that, or do I miss important meta data?

[hello_hello]

I don't have an exact answer to your question, but I think the problem is quicktime related and I've remuxed a few of those files and been given a similar warning but never had any problems with them.

From a post in another thread (which fits what you're saying about B frames):
http://forum.doom9.org/showthread.php?p=806964#post806964
"mkvmerge always shows this error when there is no ctts atom
in mp4 there is no ctts atom when no frame reordering takes place (normally when no b-frames are used)
still mkvmerge tells you it misses the ctts although there is no need for a ctts, so its kinda a misleading, not needed error message of mkvmerge"

Another thought...
The m4v container is basically a modified mp4 container (by Apple). You may find that rather than having to remux every file you can simply change the m4v extension to mp4 and your media player will handle them correctly. It's worth a shot...

[PluueeR]

I guess you're right in saying that it won't be a problem. Cause the source didn't have the ctts atom set and it's doesn't have b-frames.

If there is a problem after muxing (due to the ctts atom missing) how would that be displayed? In glitches, stuttering or sync problems?

[JohnAStebbins]

I guess you're right in saying that it won't be a problem. Cause the source didn't have the ctts atom set and it's doesn't have b-frames.

If there is a problem after muxing (due to the ctts atom missing) how would that be displayed? In glitches, stuttering or sync problems?

It would exhibit as frames that jump around in time. You would see some frames displayed out of order.

FYI, HandBrake's muxer is given an offset value for each frame. If there are no b-frames, this offset will always be 0. The muxer only adds the ctts atom when it sees a non-zero offset.