Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > New and alternative a/v containers

Reply
 
Thread Tools Search this Thread Display Modes
Old 4th August 2018, 21:59   #21  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
Quote:
Originally Posted by Snowknight26 View Post
Is the RHEL repo URL wrong?
As I don't have an RHEL installation, I only support CentOS directly.
__________________
Latest MKVToolNix is v83.0

If I ever ask you to upload something, please use my file server.
Mosu is offline   Reply With Quote
Old 4th August 2018, 22:00   #22  |  Link
Selur
Registered User
 
Selur's Avatar
 
Join Date: Oct 2001
Location: Germany
Posts: 7,259
Okay. Thanks for clearing that up.

Cu Selur
__________________
Hybrid here in the forum, homepage
Selur is offline   Reply With Quote
Old 4th August 2018, 22:13   #23  |  Link
Snowknight26
Registered User
 
Join Date: Aug 2007
Posts: 1,430
Quote:
Originally Posted by Mosu View Post
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?
Snowknight26 is offline   Reply With Quote
Old 4th August 2018, 22:28   #24  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
Quote:
Originally Posted by Snowknight26 View Post
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.
__________________
Latest MKVToolNix is v83.0

If I ever ask you to upload something, please use my file server.
Mosu is offline   Reply With Quote
Old 6th August 2018, 15:46   #25  |  Link
Snowknight26
Registered User
 
Join Date: Aug 2007
Posts: 1,430
Confirmed working on RHEL 7, thanks!
Snowknight26 is offline   Reply With Quote
Old 11th August 2018, 18:43   #26  |  Link
73ChargerFan
Registered User
 
73ChargerFan's Avatar
 
Join Date: Dec 2006
Posts: 523
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.
73ChargerFan is offline   Reply With Quote
Old 11th August 2018, 19:18   #27  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
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.
__________________
Latest MKVToolNix is v83.0

If I ever ask you to upload something, please use my file server.
Mosu is offline   Reply With Quote
Old 11th August 2018, 21:16   #28  |  Link
73ChargerFan
Registered User
 
73ChargerFan's Avatar
 
Join Date: Dec 2006
Posts: 523
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
73ChargerFan is offline   Reply With Quote
Old 11th August 2018, 22:27   #29  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
No, I'm really, really not interested in adding a lot of buttons, let alone one for this particular function.
__________________
Latest MKVToolNix is v83.0

If I ever ask you to upload something, please use my file server.
Mosu is offline   Reply With Quote
Old 14th August 2018, 02:44   #30  |  Link
hubblec4
Matroska find' ich toll
 
Join Date: Apr 2008
Posts: 1,370
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?
hubblec4 is offline   Reply With Quote
Old 14th August 2018, 16:44   #31  |  Link
mkver
Registered User
 
Join Date: May 2016
Posts: 197
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.
mkver is offline   Reply With Quote
Old 14th August 2018, 17:04   #32  |  Link
Mosu
MKVToolNix author
 
Mosu's Avatar
 
Join Date: Sep 2002
Location: Braunschweig, Germany
Posts: 4,278
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.
__________________
Latest MKVToolNix is v83.0

If I ever ask you to upload something, please use my file server.
Mosu is offline   Reply With Quote
Old 14th August 2018, 17:06   #33  |  Link
anddi
Registered User
 
Join Date: May 2018
Posts: 3
Thumbnail lost when remuxing .mkv

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?
anddi is offline   Reply With Quote
Old 14th August 2018, 18:01   #34  |  Link
hubblec4
Matroska find' ich toll
 
Join Date: Apr 2008
Posts: 1,370
@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.

Last edited by hubblec4; 14th August 2018 at 18:09.
hubblec4 is offline   Reply With Quote
Old 14th August 2018, 18:12   #35  |  Link
hubblec4
Matroska find' ich toll
 
Join Date: Apr 2008
Posts: 1,370
Quote:
Originally Posted by anddi View Post
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.

Last edited by hubblec4; 14th August 2018 at 18:56.
hubblec4 is offline   Reply With Quote
Old 14th August 2018, 19:02   #36  |  Link
anddi
Registered User
 
Join Date: May 2018
Posts: 3
Quote:
Originally Posted by hubblec4 View Post
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..
anddi is offline   Reply With Quote
Old 14th August 2018, 21:25   #37  |  Link
mkver
Registered User
 
Join Date: May 2016
Posts: 197
Quote:
Originally Posted by hubblec4 View Post
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.
Quote:
Originally Posted by hubblec4 View Post
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):
Code:
| + 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:
Code:
|+ 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):
Code:
| + 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.
mkver is offline   Reply With Quote
Old 15th August 2018, 03:59   #38  |  Link
ryrynz
Registered User
 
ryrynz's Avatar
 
Join Date: Mar 2009
Posts: 3,646
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?
ryrynz is offline   Reply With Quote
Old 15th August 2018, 11:11   #39  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,565
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.
sneaker_ger is offline   Reply With Quote
Old 17th August 2018, 21:21   #40  |  Link
Klaus1189
Registered User
 
Join Date: Feb 2015
Location: Bavaria
Posts: 1,666
Quote:
Originally Posted by anddi View Post
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
Klaus1189 is offline   Reply With Quote
Reply

Tags
matroska

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 09:50.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.