MKVToolNix v79.0 released

[Mosu]

Originally Posted by Snowknight26

Is the RHEL repo URL wrong?

As I don't have an RHEL installation, I only support CentOS directly.

[Selur]

Okay. Thanks for clearing that up.

Cu Selur

[Snowknight26]

Originally Posted by Mosu

As I don't have an RHEL installation, I only support CentOS directly.

Would you be able to make a symlink for 7 -> 7Server so that those with RHEL installations can use the RPM without having to fiddle with things manually? Or maybe clarify on the site's download page that RHEL isn't really supported?

[Mosu]

Originally Posted by Snowknight26

Would you be able to make a symlink for 7 -> 7Server so that those with RHEL installations can use the RPM without having to fiddle with things manually?

Sure. Done (both "7Server" and "7server", just to be safe). Give it a try, please.

[Snowknight26]

Confirmed working on RHEL 7, thanks!

[73ChargerFan]

Still lovin' the new GUI, but if I may request one not small feature:
A button for "new multiplexor job"

Last night I remuxed over 50 files, all using the mouse only. New job, though, requires a different brain activity (find menu, find item (on top), press it, repeat). Having a button would mostly eliminate my use of a keyboard altogether. I've got hundreds more to go. Maybe a button on the left, "New Job", beneath "Multiplexer", or right click on the job title tab?

Just thought I'd chime in... Thanks again for your hard work.

[Mosu]

I won't add any more buttons. More buttons only make things more confusing requiring more of that brain activity you're talking about.

You can easily leave the left hand on your keyboard and press Ctrl+N each time you want to create a new job.

[73ChargerFan]

Yes, but I my HTPC doesn't have one close by.

How about in the window menu, to the right of Help. A space 1/2" wide then a menu item "New Job" that doesn't open a sub-menu, but instead opens a new multiplexor job. A fakey button.

Just a thought

[Mosu]

No, I'm really, really not interested in adding a lot of buttons, let alone one for this particular function.

[hubblec4]

Hi Mosu

I have a question about the TimeStampScale.
This value is important for the length of bytes (you told me the scale factor is used to reduce bytes for storing). Default value is 1000000 and means ms-accuracy, but this makes issues with audio's and maybe also for cutting.

Can I set the TimeStampScale value to 1000000000 and now I have micro sec accuracy? How much bigger will be the resulting mkv?

[mkver]

You haven't understand this value at all: If this value is x, then the timestamps of the ordinary times (not the ones which are explicitly in ns like DefaultDuration or the DiscardPadding ones) are given by <Value encoded in File>*TimeStampScale ns; with the default value of 1000000 for TimeStampScale TimeStampScale ns = ms; with 1000000000 1000000000 ns = s. You would have s accurarcy which is useless.
If you want μs you would have to use a TimeStampScale value of 1000. Given that the relative timestamp inside (Simple)Blocks is a signed int16 you could only fit 65.536 μs of data in one Cluster; if the muxer tries to only use nonnegative relative timestamp values, it is half that value. mkvmerge does that. You would essentially have more than one cluster per video frame for ordinary framerates. The overhead will be huge.
Supplying mkvmerge with --timestamp-scale -1 will make it use such a low value that it is sample accurate even when a video track is present. This will likely still increase overhead, but not so much.
With hindsight, I believe that basing everything around ns precision was wrong. 1/9 ns would have been a better value (because then all common durations (including NTSC durations and lengths of audio samples for ordinary samplerates) would be an integral multiple of this base); or probably a file-dependent (actually segment-dependent) rational value.

[Mosu]

Yeah, even us Matroska developers agree that the choice of how to timestamp frames wasn't a good one, but one that will most likely never change as too much stuff out there wouldn't be able to handle anything else.

In order to put things into perspective: each cluster element contains at least the cluster timestamp. As a generalization you could say that at µs resolution you'd end up with roughly twelve bytes of overhead per 32ms of content. For a two hour movie you'd end up with ~ 2h * 60m/h * 60s/m * 1000ms/s * 12bytes/cluster / 32ms/cluster / 1024bytes/KB / 1024KB/MB = 2.5MB of additional overhead. Due to B frames and them being out of order, the actual overhead will often be higher (I just ran a test with a 2h movie where the additional overhead was more like 4.2MB while total file size was 1.6GB). Personally I wouldn't call either of those numbers a "huge overhead". My days of trying to fit movies on single CDs are long gone, luckily.

[anddi]

Hello! This is a very minor thing but it's bugging me. On Windows 10 when I have .mkv file with a preview thumbnail and I remux it with MKVToolNix, the preview thumbnail is lost. It's not a cover art, just a preview of the video. Is there a setting to enable it somehow?

[hubblec4]

@mkver
Yes, the value for TimeStampScale should be 1000 (not 1000000000), sorry my fault.
A vale of -1 is an automatic for mkvmerge? good to know.

@Mosu
Thanks for your test.
Have you used a "-1" value for TimeStampScale in your test? And if so, which TimeStampScale was set by mkvmerge?

For me is accuracy more important then save disk space. And Mosu's test shows that 4.2mb more overhead is almost nothing in relation to the file size.

[hubblec4]

Originally Posted by anddi

Hello! This is a very minor thing but it's bugging me. On Windows 10 when I have .mkv file with a preview thumbnail and I remux it with MKVToolNix, the preview thumbnail is lost. It's not a cover art, just a preview of the video. Is there a setting to enable it somehow?

I can remember me that someone asked the same... maybe on GitLab.
EDIT:
https://gitlab.com/mbunkus/mkvtoolnix/issues/2334

That is a Win10 issue.

[anddi]

Originally Posted by hubblec4

I can remember me that someone asked the same... maybe on GitLab.
EDIT:
https://gitlab.com/mbunkus/mkvtoolnix/issues/2334

That is a Win10 issue.

Thank you! This is exactly what I was looking for. And tbh I'm not that surprised it's a Win10 issue..

[mkver]

Originally Posted by hubblec4

Have you used a "-1" value for TimeStampScale in your test? And if so, which TimeStampScale was set by mkvmerge?

For 48kHz content (the most common sample rate for audio accompanying movies) the TimestampScale is 20832; 20833 would be enough for sample accuracy.

Originally Posted by hubblec4

For me is accuracy more important then save disk space. And Mosu's test shows that 4.2mb more overhead is almost nothing in relation to the file size.

There might be an unpleasant surprise waiting for you, namely the way mkvmerge assignes timestamps from input files. It simply trusts them and this might sound good, but it has some side-effects. By "trusts them" I mean that the timestamp of the i. frame (frame[i] - 0 based array) in a lace is set equal to Timestamp((Simple)Block) + sum the durations of all the frame[j] with j<i. This calculation is done in ns precision. Whereas the durations are fine (the error that is introduced by using ns is usually negligible; there is only one scenario in which the durations are bad: if a track is not supported (if it is supported, then the durations are directly taken from the bitstream level) and if there is no default duration for the track), the Timestamp of the (Simple)Block is not. They are after all already rounded, for a TimestampScale of 1000000 they are rounded to ms.
Here is mkvinfo's output for a file with TimestampScale 1000000 containing a DTS soundtrack (packet duration 32/3 ms):

| + Simple block: key, track number 1, 8 frame(s), timestamp 00:00:00.000000000
|  + Frame with size 1024
|  + Frame with size 1024
|  + Frame with size 1024
|  + Frame with size 1024
|  + Frame with size 1024
|  + Frame with size 1024
|  + Frame with size 1024
|  + Frame with size 1024
| + Simple block: key, track number 1, 8 frame(s), timestamp 00:00:00.085000000
|  + Frame with size 1024
|  + Frame with size 1024
|  + Frame with size 1024
|  + Frame with size 1024
|  + Frame with size 1024
|  + Frame with size 1024
|  + Frame with size 1024
|  + Frame with size 1024

If one remuxes this file with the automatically choosen TimestampScale amounting to sample precision, one gets this:

|+ Cluster
| + Cluster timestamp: 00:00:00.000000000
| + Simple block: key, track number 1, 8 frame(s), timestamp 00:00:00.000000000
|  + Frame with size 1024
|  + Frame with size 1024
|  + Frame with size 1024
|  + Frame with size 1024
|  + Frame with size 1024
|  + Frame with size 1024
|  + Frame with size 1024
|  + Frame with size 1024
| + Simple block: key, track number 1, 8 frame(s), timestamp 00:00:00.084994560
|  + Frame with size 1024
|  + Frame with size 1024
|  + Frame with size 1024
|  + Frame with size 1024
|  + Frame with size 1024
|  + Frame with size 1024
|  + Frame with size 1024
|  + Frame with size 1024

8*32/3ms = 85 1/3ms, i.e. the first lace ends at about 85 1/3 ms, but the timestamp of the second lace is very near to 85ms and not to 85 1/3ms as the timestamp is derived as above and then converted to the new TimestampScale of 20832. This is actually worse than it was before: Earlier the "incorrect" value of 85ms could be blamed upon the timestamp resolution, but this time it isn't. Put another way: With 1ms precision it could be disregarded that there is actually an 1/3ms overlap between the first two laces; now this is no longer true. The file is claming to be more precise than it actually is.

There are other ways to run into this issue: Remux a file without changing the TimestampScale, but with changing the lacing (can be done by either disabling-lacing or by changing the clustering (e.g. use a different video track that has keyframes at different points)) and you get something like this (for disable-lacing and still 1ms precision, remuxed from the first file above):

| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:00.000000000
|  + Frame with size 1024
| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:00.011000000
|  + Frame with size 1024
| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:00.021000000
|  + Frame with size 1024
| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:00.032000000
|  + Frame with size 1024
| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:00.043000000
|  + Frame with size 1024
| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:00.053000000
|  + Frame with size 1024
| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:00.064000000
|  + Frame with size 1024
| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:00.075000000
|  + Frame with size 1024
| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:00.085000000
|  + Frame with size 1024
| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:00.096000000
|  + Frame with size 1024
| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:00.106000000
|  + Frame with size 1024
| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:00.117000000
|  + Frame with size 1024
| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:00.128000000
|  + Frame with size 1024
| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:00.138000000
|  + Frame with size 1024
| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:00.149000000
|  + Frame with size 1024
| + Simple block: key, track number 1, 1 frame(s), timestamp 00:00:00.160000000
|  + Frame with size 1024

The frame with timestamp 106ms should actually have a timestamp of 106 2/3ms which should be rounded to 107ms.

A strategy to solve this problem would go like this: For the first (first/next/last etc. always refers to output order (established from the timestamps directly read from the file)) (Simple)Block of a track the timestamp in the file is trusted. Then the end timestamp of said (Simple)Block is calculated (if possible; if not, one has to trust the timestamps anyway). The next timestamp read is then compared to the end timestamp of the last one. If they agree within the bounds of the precision possible by the input file, then it is presumed that there is no gap between these two frames and instead of the timestamp of the second block the end timestamp of the first block is used. If not, then the timestamp taken from the input file is directly used. This logic is similar to the one used to prevent shifting gaps due to lacing.

If someone wants several blocks to overlap (like the 1/3ms above), then this algorithm would obviously destroy this and "correct" the file. But apart from this case (that seems to be totally unlikely) I can't think of a scenario where it would make matters worse.

[ryrynz]

Hey Mosu, any chance of prompting to change output file name automatically when only one video source file exists when swapping in/out files for new jobs?

[sneaker_ger]

Isn't that already the default? If not, look into preferences for the setting. If there is none describe in more detail what exactly you are doing, what you are expecting and what is happening instead.

[Klaus1189]

Originally Posted by anddi

Thank you! This is exactly what I was looking for. And tbh I'm not that surprised it's a Win10 issue..

Does that help?
https://forum.videohelp.com/threads/...es#post2526077