Log in

View Full Version : mkvtoolnix 4.1.1 released


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 [27] 28 29 30 31 32 33

sneaker_ger
14th December 2009, 14:36
Nope. To be honest, you're the only person who ever showed interest in this particular problem. I've already spent a lot of hours working on it during our debugging session mid-summer, and I don't consider further work on it worth the effort. I won't close the bug; maybe one day I'll find myself having some spare time and actually wanting to fix this. But I wouldn't hold my breath.

I see. I just wondered because I know that you spent much time on it and the remaining issue seems rather small to my newbie brain compared to what you've already done (more or less complete rewrite of the concerned parts). Files without NVOPs ("real" NVOPs, not those "dummies" in packed bitstream) are already working 100% nice. It's just that the timecode correction on these few not working files is done one frame too late. Since mkvmerge is the Matroska-Muxer and the support for Matroska in hardware devices is growing constantly these days the usage of native mode by default could push vendors to support it instead of the now widely used VfW mode.

buzzqw
14th December 2009, 15:20
a bit later.. but.. :thanks: Mosu MKVToolnix is an wonderful suite!

BHH

RadioactiveMan
18th December 2009, 17:52
Thanks for this nice program.

Unfortunately it looks like version 3.0.0 doesn't support drag&drop of inputfiles anymore. Is this a feature or a bug?

I'm on windows 7 enterprise 64 bit and tried it with mp4 and mkv files.

73ChargerFan
18th December 2009, 18:03
Confirmed on Win7-64 Ultimate.

Snowknight26
18th December 2009, 20:18
Works just like it has in previous versions here..

73ChargerFan
18th December 2009, 22:23
Weird, it works today. It didn't on first run.

RadioactiveMan
18th December 2009, 23:28
Weird, it works today. It didn't on first run.

same for me now. really mysterious. :confused:

Mosu
19th December 2009, 11:40
Not that mysterious at all. If you've just installed 3.0.0 and run it afterwards DIRECTLY from the installer AND your normal user account runs without administrator privileges then the mmg instance spawned by the installer will run as Administrator and not as your normal user. Drag and drop between applications running under different user accounts does not seem to work. This is not only the case with mkvtoolnix; most installation programs that offer to run the just installed program when the installation finishes let the program run as Administrator which is usually not what you want.

I'll probably change the installer's "run mmg now" checkbox to be unchecked by default.

weasel_
20th December 2009, 19:32
Why no Serbian and Croatian in Language list in v3.0.0 ?

sneaker_ger
20th December 2009, 19:42
Why no Serbian and Croatian in Language list in v3.0.0 ?

What do you mean? I've found srp and hrv. :confused:

weasel_
20th December 2009, 19:45
never mind i misslooked ;)

Mosu
20th December 2009, 19:47
Why no Serbian and Croatian in Language list in v3.0.0 ?

The language list contains the ISO639-2 codes and is sorted by them. The ISO639-2 code for Croatian is "hrv", and for Serbian it's "srp". Both entries are present, so my guess is that you were looking at the wrong place.

weasel_
20th December 2009, 20:04
Yes that was :) i use to old list ;)

tnx

73ChargerFan
20th December 2009, 21:17
I can't append VOB files from my DVD. I added VTS_02_01.VOB (identified as mpeg2), and appended 2 more, but 3.0.0 Dec12,09 build says they are h264 files, which is wrong.

sneaker_ger
20th December 2009, 21:25
That's a known issue (https://www.bunkus.org/bugzilla/show_bug.cgi?id=437). Use a vob joiner for now.

Keiyakusha
23rd December 2009, 18:22
Hi Mosu. What do you think about changing Abort button to "open folder" after muxing is done? So it will open folder where the file was saved.

Mosu
23rd December 2009, 18:43
Hi Mosu. What do you think about changing Abort button to "open folder" after muxing is done? So it will open folder where the file was saved.

Sounds useful. Maybe I'll implement it (at least for the Windows version).

neb1236
27th December 2009, 15:46
Hi, I have tried the new --without-build-timestamp but I have a resulting error (Error: The source file '--without-build-timestamp' could not be opened successfully, or retrieving its size by seeking to the end did not work.)

I have tried to put the tag in different places in the command line but didn't change anything, is anyone have tried this?

full script here (http://tinypaste.com/625f3)

Mosu
27th December 2009, 17:30
The option '--without-build-timestamp' is an option to the configure script, not a runtime option for mkvmerge.

neb1236
27th December 2009, 18:47
Thank you for the answer, but I didn't understand it, or I think I didn't.
Do you mean that this is an option for building a version of mkvmerge? And if I want to use this feature I will need to build it myself from source?
And therefore the byte-to-byte equality is about the software and not the mkv... my dream won't be granted? damn...

Mosu
27th December 2009, 18:51
That is correct. The reason this option exists is for Linux distributions to be able to build byte-identical packages of mkvtoolnix given the same library/compiler versions etc.

neb1236
27th December 2009, 18:58
So is there a possibility to have the same option for mkv muxing? maybe mkvpropedit can be useful.
I'm trying to achieve this to be able to mux a file on a distant server where I have the same source file as the local ones, without needing to download it and view it (md5 sum checking)

Mosu
27th December 2009, 19:05
No, sorry. Quoting myself and others from a recent IRC session:

21:50 Snosnhoj:: oh yeah is there a way to mux the exact same things each time to generate the exact same file with mkvmerge or some other tool.
21:55 Myrsloik:: there's a flag for that in mkvmerge
21:55 Myrsloik:: read the manual to fina it
22:05 Mosu:: Snosnhoj: no, not really
22:17 Myrsloik:: wasn't it possible before at least?
22:18 Mosu:: not really
22:18 Myrsloik:: hmm... then I have to try to giure out exactly what we did
22:19 Mosu:: there is a switch that lets mkvmerge/extract create identical files with identical options, but the resulting files are not spec compliant and may pose problematic to play back or work with. that switch is therefore not documented, and its only purpose is being used for my regression test suite
22:19 Myrsloik:: why aren't they compliant?
22:20 Mosu:: because the unique IDs are not unique; additionally all chapters/tags that use UIDs as targets are broken by that
22:21 Myrsloik:: if you ever come across some broken files...
22:22 Mosu:: :)
22:27 Snosnhoj:: thanks for the answer/details, what is the switch called?
22:28 Mosu:: don't use that switch
22:28 Mosu:: there's no reason to
22:29 Myrsloik:: now listen to the nice developer and do as he says
22:29 Mosu:: :)
22:32 Snosnhoj:: ok o;

Note that even with the configure option "--without-build-timestamps" the resulting files will not be identical.

neb1236
27th December 2009, 19:35
Understood, I will not beg for it since it will effectively result in strange file unless we can explicitly furnish custom UID for one specific mux for each track on other xml element
I will try to find third party tool which could perform a some sort of synchronization between two muxed file with same option, since the difference between the two would be very small (timestamp and segment UID)
Perhaps, one small question that could help, is the difference between two mux is compressed in the header of the file or dispatched, well I guess I can do it myself, don’t bother.
Thank you for your help

Mosu
27th December 2009, 19:42
The differences are indeed only in a very small number of elements, and those should always have the same size. Therefore syncing the two files should be nearly trivial. I cannot tell the actual elements off-hand, but they should be the various UID elements (track UID, segment UID, tag/edition/chapter/attachment UIDs), the muxing timestamp ("Date:" in mkvinfo's output), and (if you have two different sets of mkvmerge executables) the "writing app" element.

The position of these elements varies: most of them are located at the start of the file before the first cluster (track/segment/chapter UIDs, muxing timestamp, writing app). Others can be at the end of the file because mkvmerge puts them there (tag/edition/attachment UIDs).

There are two sync tools I use regularly: rsync and unison. rsync is mostly a "from point A to point B" tool, and unison is a "keep two directory structures in sync and resolve differences" tool. Therefore rsync is better suited for this particular purpose. Both are available for various Linux/Unixy systems as well as for Windows, but my experience with them on Windows hasn't been that great. However, both run over ssh and only update those parts of a file that has actually changed making them incredibly efficient for huge files with small differences.

LeXXuz
28th December 2009, 00:44
I have a question about the "--cropping" command.

Does it really tamper with the video stream by deleting specified number of macroblocks or is it just setting some kind of flag for the decoder filter to apply cropping during playback?

Mosu
28th December 2009, 08:37
I have a question about the "--cropping" command.

Does it really tamper with the video stream by deleting specified number of macroblocks or is it just setting some kind of flag for the decoder filter to apply cropping during playback?

The latter. mkvmerge is not an encoder/decoder, and the cropping parameters are only stored in the track headers. It's up to the decoding chain to honor them and use the appropriate filters.

neb1236
28th December 2009, 13:01
I thought it could be interesting for other to see if it was trivial or not, well it is.
First thank you for the name of rsync Mosu, I already knew the name but I couldn't recover it, you saved me some time.
Here is the result:

- 6 mkv total of 4.09Go
- Sent: 436Ko Received: 1.08Mo
- Achieved in 4 min and 10 sec
Limited by a slow P4@2.8ghz processor and done through a 100ko/s upload and 50ko/s download broadband restriction.
- rsync effectiveness: 2774!!!

Mkv made with same version of mkvmerge with identical batch and source files
Made between a Windows XP and Windows 7 desktop, I didn't used rsync under cygwin but a modded rcync for windows called DeltaCopy (work good with mix linux/win server/client too)

I knew it was an effective technique, but it has surpassed my expectation.

Mosu
28th December 2009, 13:40
Nice numbers indeed :) Ah yes DeltaCopy; I actually know that one but didn't think of it. Anyway, glad to see you've got a working solution.

smok3
28th December 2009, 20:55
how would i split mkv to lil mkvs by chapters?

mkvmerge GUI v2.4.1 ('Use Me')
built on Dec 13 2008 21:02:59
(ubuntu)

Mosu
28th December 2009, 21:00
mkvmerge cannot split by chapters (neither in current versions -- 2.4.1 is rather old, btw). It can split by timecodes, but you'll have to get the chapter start times manually and use them as the split timecodes.

smok3
28th December 2009, 21:24
you'll have to get the chapter start times manually and use them as the split timecodes

thanks, that was actually the 2nd thing i tried, i have problems with required format i guess this:

HH:MM:SS, HH:MM:SS, HH:MM:SS
or this
HH:MM:SS.MS, HH:MM:SS.MS, HH:MM:SS.MS

is not the right thing? wrong delimiter?

edit:
here is the data as reported by mediainfo;
00:00:00.000
00:00:15.880
00:05:02.440
00:05:18.280
00:10:05.320
00:10:21.160
00:15:07.240
00:15:23.080
00:20:09.640
00:20:25.480
00:25:12.520
00:25:28.360
00:30:14.920
00:30:31.240
00:35:17.320
00:35:33.160
00:40:19.720
00:40:35.560
00:45:22.120
00:45:37.960

Mosu
28th December 2009, 21:33
Quoting the documentation (http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html) for the "--split" option:

--split size:<d[k|m|g]> or shorter --split <d[k|m|g]>
--split duration:<HH:MM:SS.nnnnnnnnn|ns> or shorter --split <HH:MM:SS.nnnnnnnnn|ns>
--split timecodes:A[,B[,C...]]

Splits the output file after a given size or a given time. Please note that tracks can only be split right before a key frame. Due to buffering mkvmerge will split right before the next key frame after the split point has been reached. Therefore the split point may be a bit off from what the user has specified.
At the moment mkvmerge supports three different modes.
1. Splitting by size.
The parameter d may end with k, m or g to indicate that the size is in KB, MB or GB respectively. Otherwise a size in Bytes is assumed. After the current output file has reached this size limit a new one will be started. The size: prefix may be omitted for compatibility reasons.
2. Splitting after a duration.
The paramter must have the form HH:MM:SS.nnnnnnnnn for specifying the duration in up to nano-second precision or a number n followed by the letter ’s’ for the duration in seconds. "HH" is the number of hours, "MM" the number of minutes, "SS" the number of seconds and "nnnnnnnnn" the number of nanoseconds. Both the number of hours and the number of nanoseconds can be omitted. There can be up to nine digits after the decimal point. After the duration of the contents in the current output has reached this limit a new output file will be started. The duration: prefix may be omitted for compatibility reasons.
3. Splitting after specific timecodes.
The parameters A, B etc must all have the same format as the ones used for the duration (see above). The list of timecodes is separated by commas. After the input stream has reached the current split point’s timecode a new file is created. Then the next split point given in this list is used. The timecodes: prefix must not be omitted.
For this splitting mode the output filename is treated differently than for the normal operation. It may contain a printf like expression ’%d’ including an optional field width, e.g. ’%02d’. If it does then the current file number will be formatted appropriately and inserted at that point in the filename. If there is no such pattern then a pattern of ’-%03d’ is assumed right before the file’s extension: ’-o output.mkv’ would result in ’output-001.mkv’ and so on. If there’s no extension then ’-%03d’ will be appended to the name.

If you use the command line then you really, really do have to use the format's name (e.g. "--split timecodes:00:05:00,00:12:41"). If you use mmg then you only need to enter the list of timecodes into the input box.

Mosu
28th December 2009, 22:11
Hey,

I've implemented reading multiple VOBs that logically belong together as if they were a single big file. Here's the ChangeLog entry that should make clear what I mean:

* mkvmerge, mmg: new feature: If a MPEG-2 program stream file is added to mkvmerge whose base name ends in a number then mkvmerge will automatically read and process all other files in the same directory with the same base name, same extension and different numbers. Those files are treated as if they were a single big file. This applies e.g. to VOB files from DVD images that are named VTS_01_1.VOB, VTS_01_2.VOB, VTS_01_3.VOB etc. mmg will output an error message if the user tries to add or append one of the other files that mkvmerge will process automatically (e.g. if the user has added VTS_01_1.VOB already and tries to append VTS_01_2.VOB).

This also fixes bug 437.

I certainly need some folks to test this. I've successfully muxed files on both Windows and Linux.

This also means that mkvmerge will still detect VOB files from the middle of such a set as e.g. h264 instead of MPEG-2 if you decide to add e.g. VTS_01_3.VOB instead of VTS_01_1.VOB -- don't do that :)

BTW: No, this of course does not mean that mkvmerge can read directly from encrypted DVDs. It does not contain decryption routines.

Here's the link to the Windows build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-3.0.0-build20091228-193-setup.exe

smok3
28th December 2009, 22:21
Thanks again, what fixed the problems was one or more of this things:

1. remove the repo version (old one), mkvtoolnix + gui
2. install the debs (jaunty amd64):
mkvmerge GUI v3.0.0 ('Hang up your Hang-Ups') built on Dec 12 2009 19:13:47
3. paste timecodes like '00:00:00.000,00:05:02.440,00:10:05.320,00:15:07.240,00:20:09.640'

to admin: this was probably the wrong thread, posts:
1330-1333 + 1335 could make a cute lil thread named 'how would i split mkv to lil mkvs by chapters?'
sorry about that...

73ChargerFan
28th December 2009, 23:17
I certainly need some folks to test this.
Thanks for being motivated! My first test came out fine on Win7. I'll test with a few other dvds.

nkk
29th December 2009, 15:02
Why mkvmerge GUI does not allow manage ChapterSegmentUID XML tag in Chapter editor?

Mosu
29th December 2009, 15:33
No particular reason.

73ChargerFan
29th December 2009, 18:47
I tested on a dvd with more than one title, (vts_02_ ...) and it works fine. The change's I'd make is to state in the change log that this is tested only with dvd vob files, and an indication in mmg when adding the first file that it is also loading files +02 +03 etc. instead of the warning message.

Mosu
29th December 2009, 18:52
The change's I'd make is to state in the change log that this is tested only with dvd vob files,

I've done this already after posting the announcement above.

and an indication in mmg when adding the first file that it is also loading files +02 +03 etc. instead of the warning message.

Good idea. I'll keep the error message, though.

Brother John
30th December 2009, 23:27
Hi,

I’ve found a small bug in MMG’s (3.0.0 on Windows) setting »File / Options / mmg / Use this directory«. When you enter a path with a backslash at the end here, the auto-created output filename in the main window will wrongly contain a double backslash before the actual file name.

Edit:
At least with Win XP that double backslash doesn’t have any negative effects. Muxing still works as expected. Still looks weird, though.

Mosu
31st December 2009, 09:52
Double backslashes (on Windows) and double slashes (on Linux, Mac) don't change the directory. Only at the beginning of the file name are double backslashes interpreted differently then a single one (as a network path).

Atomic420
1st January 2010, 08:08
On the same subject as output file names, with MKVMerge (3.0.0 Windows) would it be possible to add some character to the default output file name?
As it is the default is exactly the same as the input file name, so if you inadvertently click to start the operation it will overwrite the source file.
So source is "video.mkv" new default output something like "video(2).mkv"

Thanks for this great app and .... HAPPY NEW YEAR!

Brother John
1st January 2010, 17:02
@Mosu
Ah, ok. Learned something new again. Thx. I still think those double backslashes might confuse users. But it only happens under such unlikely circumstances that it’s probably not worth spending any effort on; unless you’re extremely bored of course. :)

Mosu
2nd January 2010, 19:16
On the same subject as output file names, with MKVMerge (3.0.0 Windows) would it be possible to add some character to the default output file name?
As it is the default is exactly the same as the input file name, so if you inadvertently click to start the operation it will overwrite the source file.

Actually it won't -- mkvmerge will output an error message in such a case and will not start muxing. That being said:

So source is "video.mkv" new default output something like "video(2).mkv"

I think this is a good idea, and here's a build that does exactly that: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-3.0.0-build20100102-199-setup.exe

Mosu
3rd January 2010, 15:03
Hi Mosu. What do you think about changing Abort button to "open folder" after muxing is done? So it will open folder where the file was saved.

Aaaaand here it is: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-3.0.0-build20100103-200-setup.exe

Keiyakusha
3rd January 2010, 16:32
Aaaaand here it is: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-3.0.0-build20100103-200-setup.exe

That's great! :thanks:

smok3
6th January 2010, 23:33
report: the bins provided by jonthn seems to work fine on osx snow leopard - v 3.0.0.

bigpapa4u
7th January 2010, 02:41
Thanks for the great app ...

Happy New Year everyone!:thanks::thanks::thanks:

stax76
10th January 2010, 17:52
@Mosu

I noticed there is a GUI for mkvinfo, besides mmg are there other GUIs included?

Maybe you could add mkvinfo showing a file extension for each stream so applications don't need to maintain a dictionary, I'm not sure if my dictionary is up-to-date and bug free, where do I find which formats are currently supported by mkvextract?

Dim dic As New Dictionary(Of String, String)

dic("A_AAC") = "aac"
dic("A_AC3") = "ac3"
dic("A_DTS") = "dts"
dic("A_FLAC") = "flac"
dic("A_MPEG/L1") = "mpa"
dic("A_MPEG/L2") = "mp2"
dic("A_MPEG/L3") = "mp3"
dic("A_PCM/INT/LIT") = "wav"
dic("A_QUICKTIME") = "qdm"
dic("A_REAL") = "ra"
dic("A_TTA1") = "tta"
dic("A_VORBIS") = "ogg"
dic("A_WAVPACK4") = "wv"
dic("Attachment") = "att"
dic("Chapters") = "Chapters"
dic("S_TEXT/ASS") = "ass"
dic("S_TEXT/SSA") = "ssa"
dic("S_TEXT/USF") = "usf"
dic("S_TEXT/UTF8") = "srt"
dic("S_VOBSUB") = "idx"
dic("Tags") = "Tags"
dic("V_MPEG1") = "m1v"
dic("V_MPEG2") = "m2v"
dic("V_MPEG4/ISO/ASP") = "m4v"
dic("V_MPEG4/ISO/AVC") = "h264"
dic("V_MS/VFW/FOURCC") = "avi"
dic("V_REAL") = "rmvb"
dic("V_THEORA") = "ogg"