MKVToolNix v24.0.0 released

[v0lt]

I downloaded the video stream (747MB hd1080 video/mp4) from here and packed in mkv using mkvmergeGUI v7.9.0. But mkv file freezes when rewinding in MPC-BE and MPC-HC. With mp4 file no such problem.

[Mosu]

Thanks for the report. Turns out that key frame detection was completely broken for video tracks in MP4 DASH files. I've fixed the issue and uploaded pre-build 749 which includes the fix.

[v0lt]

Thank you. Pre-build 749 works correctly.

[NikosD]

Hello.

Is it possible to mux this m2ts file to MKV, keeping the original frame rate ?

Sample here:
https://www.sendspace.com/file/igxqjm

With mp4 and mov containers, there is no problem.

[sneaker_ger]

I don't see any problem?
mkvmerge -o output.mkv input.m2ts
Plays like source.

/edit:
Oh, I see. You probably mean MediaInfo. You better provide more solid proof by showing timecodes are wrong. MediaInfo is not reliable.

[NikosD]

With what frame rate ?

Does it keep the original 59.940 or changes it to 59.880 ?

[Mosu]

Obligatory note about frame rates in Matroska: https://github.com/mbunkus/mkvtoolni...rate-displayed

Short summary: Matroska doesn't store that piece of information. If playback works correctly then everything's OK.

[sneaker_ger]

Originally Posted by NikosD

With what frame rate ?

Does it keep the original 59.940 or changes it to 59.880 ?

No, looking pretty much exactly correct here. There is a delay at start, maybe that messes up your calculation? (I averaged by taking timecode of last picture minus delay divided by number of pictures. As Mosu said there isn't really any authorative fps value.)

[NikosD]

Thanks, but I think that MKV has also some limitations regarding its timebase accuracy of 1ms and it's difficult to handle frame rate of 60000/1001 for example, like the sample.

[huhn]

Originally Posted by NikosD

Thanks, but I think that MKV has also some limitations regarding its timebase accuracy of 1ms and it's difficult to handle frame rate of 60000/1001 for example, like the sample.

who said it is limited to 1ms accuracy?

mkv can do 24000/1001 and 60000/1001 just fine.

[nevcairiel]

Originally Posted by NikosD

Thanks, but I think that MKV has also some limitations regarding its timebase accuracy of 1ms and it's difficult to handle frame rate of 60000/1001 for example, like the sample.

1ms is the default accuracy, but it can use any other, higher or lower.

[Zenitram]

Originally Posted by huhn

who said it is limited to 1ms accuracy?

mkv can do 24000/1001 and 60000/1001 just fine.

Just fine???

First, I wish to find 24000/1001 files without the default TimeCodeScale of 1 ms. Currently I have files with only the default TimeCodeScale, and it is not easy to detect 24000/1001 vs 24000/1000.

Second, I wonder, even in theory, how you can do 24000/1001 just fine : if I understand well the spec, the precision of the time code can be maximum 1 nanosecond. unfortunately, the duration of a frame at 24000/10001 is 41708333.3333333333333 nanoseconds, wich can not be represented "just fine" even with a TimeCodeScale of 1 nanosecond.

Maybe I miss something, but in that case please provide a MKV file with "60000/1001 just fine" ("just fine" means without any rouding, else it is a not "just fine", it is "unprecise due to technical limitations i.e. no numerator/denominator pair, but not too much unprecises so it is ok at least for me"). MP4/MOV, for example, stores a frequency e.g. the frequency is set to 60000 and the timecode is 1001 for the 2nd frame, and it is just fine (it is exactly, without any rounding, the presentation time of the frame)

That said, having a 1 ms precision is enough for most users (including me for personnal use). Just "not fine" for some people who are not "most users" (including me for professional use).

Originally Posted by sneaker_ger

Oh, I see. You probably mean MediaInfo. You better provide more solid proof by showing timecodes are wrong. MediaInfo is not reliable.

I (the developer of MediaInfo) confirm that MediaInfo is not reliable about frame rate detection (due to the 1 ms precision ;-), I need to estimate the frame rate based on the unprecise time stamp and sometimes the algo provides wrong result, it is on my toto-list to have a more precise algorithm and also read the new tags Mosu has implemented).

[Mosu]

It's true that 24000/1001 is a rational number, but that doesn't mean that you cannot express timecodes properly. As long as you don't calculate the timecode of frame n by adding something on top of the timecode of frame n - 1 but by multiplying the frame number by the frame rate (or as long as you do all your internal calculations taking the rounding error into account and only rounding to the container's precision when writing out that frame) you're good to go.

[nevcairiel]

TimeCodeScale does not have to be 1ms or 1ns, it would be feasible to use some odd number to reproduce 24000/1001 exactly if a muxer wanted to do that. But alas, no MKV muxer seems to use that freedom.

[Mosu]

The problem with selecting such a time code scale value would be that it would affect the time codes of all time codes in the file, e.g. the audio ones, too. This may pose problems with audio playback – but I haven't actually tested it.

BTW, a couple of days ago I made a few unscientific tests with other time code scale values. Switching frmo 1ms to 1us precision (* 1000) resulted in an overall increase in file size of 0.12%, and going from 1ms to the maximum of 1ns (* 1000000) resulted in an increase of 0.20%. I'm actually considering switching to us precision by default for a release or two and see what happens.

[Zenitram]

Originally Posted by Mosu

you're good to go.

Mosu, sorry but some people don't agree about rounding (even rouding at 1 ns).
For them, 41708333 nanoseconds is not equal to 1001/24000.

Can you put in MKV the exact value 1001/24000 (or 3754/90000, MPEG-TS has a frequency of 90 kHz) for the time code of a frame? If not, some people are not good to go because I cannot express timecodes properly.

Please provide a hint about having proper timecodes with 1001/24000 i.e. being able to say that the 2d frame is at 41708333.3333333333333... nanoseconds (actually a way to provide a rational number) instead of 41708333 nanoseconds (whih is not the proper timecode), else for the moment I understand it is not possible to have proper timecodes, only a rounding.

Again, I fully understand it is more than enough for most people, it is just not "proper" timecode for people wanting more (actually the exact, without any rounding, never) precision. I also fully understand that it can not be easily changed due to Matroska design, and the goal is not to blame you, I understand that Matroska was not designed with such people in mind (and I didn't design MediaInfo with them in mind too, e.g. I show "29.970 fps" for 30000/1001 fps but some people want to be able to do the difference between 30000/1001 fps and 29970/1000 fps, even if the difference is only ~0.0001%, it is important for them)

Originally Posted by Mosu

The problem with selecting such a time code scale value would be that it would affect the time codes of all time codes in the file, e.g. the audio ones, too. This may pose problems with audio playback – but I haven't actually tested it.

Another design issue of Matroska ;-).
Time scale should be per track (24000/1001, 48000/1...), not per file. Anyway, it happens, we can not think to all when a format is designed.

Originally Posted by Mosu

BTW, a couple of days ago I made a few unscientific tests with other time code scale values. Switching frmo 1ms to 1us precision (* 1000) resulted in an overall increase in file size of 0.12%, and going from 1ms to the maximum of 1ns (* 1000000) resulted in an increase of 0.20%. I'm actually considering switching to us precision by default for a release or two and see what happens.

I speak of it, but I don't want to make you change your mind "just for me", 0.20% is not so small, Matroska is appreciated also for its small overhead and that usage (more than 1 ms of precision) is for very specific users who will not be a lot more happier because it is still not precise enough from their point of view.
I think that letting the end user choose the TimeCodeScale and letting default to 1ms is not bad.
I would argue more for having a "tag_framerate" tag with a rational number (e.g. "24000/1001") when you can have this value from the source (e.g. from MP4 track header) but the tag_duration and tag_number_of_frames are already good stuff (maybe adding a tag when the frame rate is not constant?).

Originally Posted by nevcairiel

it would be feasible to use some odd number to reproduce 24000/1001

Give the numbers... I don't see how. because you can not express such number in nanosecond...

[huhn]

you are aware that even with 1ns you are still rounding. PCs are doomed to round numbers at some point no matter what you do.

[Zenitram]

Originally Posted by huhn

you are aware that even with 1ns you are still rounding. PCs are doomed to round numbers at some point no matter what you do.

Sorry to inform you that e.g. MP4 can provide time codes without any rounding (it provides num and den: 2nd frame time code is 1001/60000, exactly, no rounding). Please read again my previous comment.
Rounding number during display in order to fit limitations of the player (lose of information is not important, it is displayed then trashed) is totally different than storing a rounded number in a file (information is lost forever).

Again, I totally understand that most people don't care of precise time codes, but some other people do care. 1000/1001 frame rates are a mess, but they do exist, and 30000/1001 is not 29970/1000 for some people.

[foxyshadis]

Originally Posted by Zenitram

Sorry to inform you that e.g. MP4 can provide time codes without any rounding (it provides num and den: 2nd frame time code is 1001/60000, exactly, no rounding). Please read again my previous comment.
Rounding number during display in order to fit limitations of the player (lose of information is not important, it is displayed then trashed) is totally different than storing a rounded number in a file (information is lost forever).

Again, I totally understand that most people don't care of precise time codes, but some other people do care. 1000/1001 frame rates are a mess, but they do exist, and 30000/1001 is not 29970/1000 for some people.

Another instance where MediaInfo needs "better parsing" and maybe "full parsing" options. People request that for bitrate all the time, but you could certainly make framerate more precise by parsing a few minutes of frames.

[Zenitram]

Originally Posted by foxyshadis

Another instance where MediaInfo needs "better parsing" and maybe "full parsing" options. People request that for bitrate all the time, but you could certainly make framerate more precise by parsing a few minutes of frames.

It is not a thread about MediaInfo so a very quick answer: it is always a problem of performance, lot of users already complain about parsing too many frames in the default behavior (too much slow with "only" few frames, and "few minutes of frames" means sometimes few Gigabytes of data to read from HDD), and full parsing option is already implemented for some customers with specific needs with a very precise computing of lot of things. It is just not available in the GUI and for Matroska specificly because nobody considered to sponsor such feature. But it will change in the near future because there is now a sponsoring of improvement of Matroska parsing, check MediaConch project for more information.

Additionaly, Mosu fixed the issue about missing bitrate with statistic tags so I "just" need to implement them on my side, without the need to parse the whole file (also planned during hte development of MediaConch). MediaInfo will have a far better support of Matroska in the upcoming months.