[JEEB]

Originally Posted by osgZach

See this thread

Matroska VFR Proof of Concept



Last time I used it, TFM's automatic method output a different format. Whatever Matroska is doing with that data internally I do not know, and is beside the point. Muxing with V1 timecodes does not give me problems with my WDTVLive, whereas TFM's auto method would produce unplayable files. Huge corruption/blocking/pauses/skipping.

In any case. I've given him a solution that is just as valid all the same, and IMHO more compatible if he has concerns about set-top media players.

OK, no problem with YATTA (which, albeit being a gigantic PITA, is a relatively useful tool). But those statements are just... quite illogical.

• MKVMerge takes in V1 and V2 timecodes
• Matroska has an internal timescale, that by default is 1 millisecond, and all frames have a timecode of this precision
• With V1 timecodes the timecodes are calculated by the muxer from the framerates marked
• With V2 timecodes the timecodes are calculated from the per-frame timecodes, which are basically "the amount of milliseconds passed" (and thus in case of integer precision only used, can be thought to be used practically as-is with the default timescale)
• Thus, Matroska has no real "framerates" at all, and in most cases the output of V1 and V2 timecodes in the case of same source is exactly the same on the output side

Are you sure you are not making false links between things? Are you sure it's not, say, header compression, that your playback device is having problems with (which is well-known, and was fixed for some players lately in a firmware update)?

Also, it could of course be a bug in the player's matroska parsing code in case of a non-standard timescale, f.ex., but that wouldn't be a case of "V2 timecodes is the problem!", to be honest, since you'd have to set that one by yourself. Also, you might just want to use mkvinfo and compare the internal timecodes of the video track in the final cases (mkvinfo -s filename.mkv outputs the timecodes of every frame for the given matroska file's tracks [yes, audio included]). Also, old mkvmerge versions had problems with timecode files (old bugs).

Bringing this to a conclusion:

You problem is most probably:

1. Header compression (mkvmerge 3.4 was the last version without it being on automatically, and from 4.4 you can now set it to be off by default for certain types of tracks from the settings)
2. Old mkvmerge (older than 2.2?)
3. Timescale bug in the player if you are using a non-default timescale (?)
4. Weird timecode bug in the player (?)

All I am asking is that before you start spouting out things that might stick as a "user myth" even if they are not true, please make sure you understand the things at hand and know the exact cause of the problem. Thank you.