Log in

View Full Version : MKVToolNix v24.0.0 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 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105

Mosu
4th September 2010, 20:46
I'm pretty sure the two posts were moved here from another thread, one about MP4Box.

Mosu
5th September 2010, 11:02
I've released mkvtoolnix v4.3.0. It contains a lot of bug fixes and a few enhancements but no major new features.

There's one change for people building from source in general and package maintainers in particular: the build system has been changed from "make" to "rake". Here's the ChangeLog entry:

* build system: The build system has been changed from "make" to "rake", the Ruby based build tool. MKVToolNix includes its own copy of it so all you need is to have Ruby itself installed. The build proecss has been tested with Ruby 1.8.6, 1.8.7 and 1.9.1. Building is pretty much the same as before: "./configure", "./drake", "sudo ./drake install". Most of the build targets have similar if not identical names, e.g. "./drake install". You can override variables just like with make, e.g. "./drake prefix=/somewhere install".

Adjusting build scripts should be easy enough. If you need any help just let me know.

Here are the usual links...

...to the home page:
http://www.bunkus.org/videotools/mkvtoolnix/

...to the source code:
http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-4.3.0.tar.bz2

...to the Windows installer and 7zip archive:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.3.0-setup.exe
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.3.0.7z

All binaries that I provide myself have already been uploaded.

Here's the full ChangeLog since release 4.2.0:

------------------------------------------------------------
2010-09-04 Moritz Bunkus <moritz@bunkus.org>
* Released v4.3.0.
* mkvmerge: bug fix: Appending tracks which would normally be compressed (e.g. with header removal compression) and turning off compression for those tracks with "--compression TID:none" (or the corresponsing option in mmg) was resulting in the second and all following appended tracks to be compressed all the same.

2010-09-01 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix: Errors such as 'file does not exist' did not cause mkvextract to quit. Instead it continued and exited with the result code 0.

2010-08-28 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Certain frames in certain h.264/AVC raw tracks were handled wrong, e.g. files created by x264 versions starting with revision 1665. The situation occured if an IDR slice comes immedtiately after a non-IDR slice and the IDR slice has its frame_num and pic_order_count_lsb fields set to 0.

2010-08-26 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: Attachments will be rendered at the beginning of the file again. Fix for bug 516.

2010-08-24 Moritz Bunkus <moritz@bunkus.org>
* mkvpropedit, mmg's header editor: Fixed a crash corrupting files in certain situations. If the updated header fields required filling exactly one byte with an EbmlVoid element and if the next Matroska element's "size" was already written with its maximum length (8 bytes) then the crash would occur. Such files are written by e.g. lavf. Fix for bug 536.

2010-08-17 Moritz Bunkus <moritz@bunkus.org>
* All: bug fix: Fixed a couple of format strings in translations which could cause the programs to crash.

2010-08-14 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: new feature: mkvinfo will show the h.264 profile and level for AVC/h.264 tracks along with the CodecPrivate element.

2010-08-10 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Video tracks with a width or height of 0 are not read from AVI files anymore. Fix for bug 538.

2010-08-05 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed an error with losing packets (error message "packet queue not empty") when reading IVF (VP8) files using --default-duration on it.
* mkvmerge: bug fix: Fixed access to uninitialized memory in the MPEG-2 ES parser.

2010-08-03 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: The 'total remaining time' shown by the job manager was totally wrong. Fix for bug 529.

2010-08-01 Moritz Bunkus <moritz@bunkus.org>
* build system: The build system has been changed from "make" to "rake", the Ruby based build tool. MKVToolNix includes its own copy of it so all you need is to have Ruby itself installed. The build proecss has been tested with Ruby 1.8.6, 1.8.7 and 1.9.1. Building is pretty much the same as before: "./configure", "./drake", "sudo ./drake install". Most of the build targets have similar if not identical names, e.g. "./drake install". You can override variables just like with make, e.g. "./drake prefix=/somewhere install".

2010-07-30 Moritz Bunkus <moritz@bunkus.org>
* mmg header editor: bug fix: If a file was loaded that did not contain 'track language' elements and those elements were unchanged then they would be set to 'und' upon saving. Now they're left as-is, and when adding them to the file the drop-down box defaults to 'eng' being selected as per Matroska default value specifications. Fix for bug 525.

2010-07-29 Moritz Bunkus <moritz@bunkus.org>
* mkvextract, mkvinfo, mkvpropedit: new feature: Added the option "-q" and its long version "--quiet". With "--quiet" active only warnings and errors are output. Fix for bug 527.
* mkvmerge: bug fix: The option "--quiet" was not working properly.
* mkgmerge: bug fix: mkvmerge was treating SSA/ASS subtitle files as audio files for the purpose of track selection (--no-subtitles / --no-audio). Fix for bug 526.
------------------------------------------------------------

Have fun.

b66pak
5th September 2010, 18:44
thanks a lot...
_

hubblec4
5th September 2010, 18:52
Thumps up Mosu

Pulstar
5th September 2010, 21:26
I'm pretty sure the two posts were moved here from another thread, one about MP4Box.

Thanks, it worked! But such a time-consuming process. :eek:

mandarinka
6th September 2010, 02:14
2010-08-28 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Certain frames in certain h.264/AVC raw tracks were handled wrong, e.g. files created by x264 versions starting with revision 1665. The situation occured if an IDR slice comes immedtiately after a non-IDR slice and the IDR slice has its frame_num and pic_order_count_lsb fields set to 0.


Can we have some specifics about this behavior? It sounds like that creates problems (decoding corruption, wrong timestamps?), what should one look for?

Thanks!

Sharktooth
6th September 2010, 03:03
corrupted output on some frames in your encodes.

Mosu
6th September 2010, 07:51
Can we have some specifics about this behavior? It sounds like that creates problems (decoding corruption, wrong timestamps?), what should one look for?

Thanks!

Details are in this post and that whole thread in general.

Video Dude
7th September 2010, 18:25
Big companies are definitely in a hurry to support this feature. Why? Cuz not supporting it renders their player useless w/ anything encoded online using the new mkvtoolnix. They will have no choice but to fix their implementation (as more and more releases are muxed w/ this new feature). I give it a month for >75% of them to release firmware updates.
Or they could drop MKV support due to user complaints of files not working.

Superb
7th September 2010, 19:55
Or they could drop MKV support due to user complaints of files not working.Sure, like that could happen. A 2010 media streamer which drops support for the most common format used for online (and usually illegal) HD encodes.

Devport
8th September 2010, 00:26
Bug : mkvmerge-gui doesn't mux video if individual tracks aren't added in a certain order.

If I have two or more tracks, e.g.

test.mp2
test.m2v

and add them all at once to mkvmerge-gui by drag and drop it will only mux the audio tracks ignoring the video track even though all tracks are shown in the ui. If I add the tracks manually in a certain order only ( it has to be 1. *.mp2, 2. *.ac3, 3. *.m2v ) mkvmerge-gui will mux all tracks correctly. Same applies if there is an additional ac3 track.

Seems to be a bug to me. Version is 4.3.0 from your ppa for Ubuntu. I don't know if that happened in previous versions but I suppose it didn't.

edit : Corrected required file order

[)370|\|470!2
11th September 2010, 22:05
Files (x264 video, AC3 or DTS audio) muxed with 4.2.0 cause WD Live TV to stuck.
Yet another good reason not to use mkvtoolnix. Ever.

7ekno
12th September 2010, 03:52
Yet another good reason not to use mkvtoolnix. Ever.

Nah, just a great way to cull those that can't read :P After all, they and those that tend to believe blatent false statements are the biggest whingers :P Win Win ...

7ek

LeMoi
15th September 2010, 23:58
When appending multiple mkv files with chapters, there are errors in the timestamps
http://img36.imageshack.us/img36/4677/avinaptic.jpg
Look between Chapitre n°13 and Chapitre n°1, end of first chapter is not saved correctly. That results in chapters after Chapitre n°13 not displayed during playback (they don't appear in MPC menu, using Haali Media Splitter), but seeking file from beginning to the end works fine (5h25 movie).
Is this an error from first muxed file, which should have an end timing for this chapter ?

Mosu
16th September 2010, 07:38
When appending multiple mkv files with chapters, there are errors in the timestamps
http://img36.imageshack.us/img36/4677/avinaptic.jpg
Look between Chapitre n°13 and Chapitre n°1, end of first chapter is not saved correctly.

In a Matroska file there are two elements that select a chapter's start end end timestamp: ChapterTimeStart and ChapterTimeEnd. The first one is mandatory, the second one isn't. If there is no ChapterTimeEnd entry for a given chapter level (in Matroska chapters can be nested) then a player must assume that the chapter ends when the next chapter on the same level starts or at the end of the chapter one level above the current chapter if the current chapter is nested.

mkvmerge will not add ChapterTimeEnd entries itself. This is not a bug.

drob
16th September 2010, 11:15
Is there a way to tell via mediainfo or similar utils, if header compression was applied?

Atak_Snajpera
16th September 2010, 11:53
http://forum.doom9.org/showthread.php?p=1420306#post1420306

Kurtnoise
16th September 2010, 16:10
Is there a way to tell via mediainfo, if header compression was applied?
this is already implemented into the lib in internal but not available through the interface. Maybe using it in debug mode...

Zenitram
16th September 2010, 16:24
this is already implemented in internal but not available through the interface. Maybe using it in debug mode...

Oh, this feature is requested...
I added it to all displays:
Video
ID : 1
Format : MPEG-4 Visual
Muxing mode : zlib
Codec ID : DX50
Codec ID/Hint : DivX 5
Duration : 8s 560ms
Width : 720 pixels
Height : 400 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0

Audio
ID : 2
Format : MPEG Audio
Muxing mode : zlib
Codec ID : A_MPEG/L3
Codec ID/Hint : MP3
Duration : 8s 568ms
Channel(s) : 2 channels
Sampling rate : 48.0 KHz

In SVN and next official version.

SeeMoreDigital
16th September 2010, 20:33
In SVN and next official version.Nice one :)

LeMoi
16th September 2010, 21:27
In a Matroska file there are two elements that select a chapter's start end end timestamp: ChapterTimeStart and ChapterTimeEnd. The first one is mandatory, the second one isn't. If there is no ChapterTimeEnd entry for a given chapter level (in Matroska chapters can be nested) then a player must assume that the chapter ends when the next chapter on the same level starts or at the end of the chapter one level above the current chapter if the current chapter is nested.

mkvmerge will not add ChapterTimeEnd entries itself. This is not a bug.

So why bothering allowing appending a file to another with chapters if chapters are not appended correctly ?

Mosu
16th September 2010, 22:54
Huh? They are. Why do you assume mkvmerge is wrong in this case? It is not a muxer's job to interpret the absence of ChapterTimeEnd elements correctly; it's the _player's_ job.

Let's assume you have file A has three chapters, A1 - A3. A3 does not have a ChapterTimeEnd element. Let's further assume file B has two chapters, B1 and B2. Usually B1's ChapterTimeStart element is 00:00:00 (common case when splitting at chapter boundaries). When appending B to A mkvmerge will adjust all ChapterTimeStart and ChapterTimeEnd elements for the chapters in B by the length of A. So if a player sees chapter A3 without a ChapterTimeEnd element it will also see chapter B1 starting after A3 starts and therefore use B1's start time as the end time for A3. This pretty much what the user wants and expects.

LeMoi
18th September 2010, 14:48
Problem is the splitter, not the player, isn't it? Haali's Media Player only displays first chapters, that have ChapterTimeEnd, not the following


EDIT: sorry I was wrong, i identified the problem: resulting file doesn't have one chapter edition with all chapters in it, but 3 editions, each one containing chapters of original file, but with final timings. If I want to access all chapters, I have to switch from an edition to another one, meaning that i'll have access for only a part of the chapters, not all. This is a muxing 'bug', isn't it? Or is it expected result?

http://img826.imageshack.us/img826/3881/mmge.jpg

Mosu
18th September 2010, 17:21
EDIT: sorry I was wrong, i identified the problem: resulting file doesn't have one chapter edition with all chapters in it, but 3 editions, each one containing chapters of original file, but with final timings. If I want to access all chapters, I have to switch from an edition to another one, meaning that i'll have access for only a part of the chapters, not all. This is a muxing 'bug', isn't it? Or is it expected result?

Each edition has its own UID (mandatory element). If two editions in appended files have the same UID then mkvmerge will put the chapters into a single UID in the output file. It won't merge chapters from editions with different UIDs into one edition though. So yes, this is the expected result if the UIDs are different.

LeMoi
18th September 2010, 21:58
So how am I supposed to make editions have same UID?

EDIT: found in chapter editor

LeMoi
18th September 2010, 22:14
OK, now it works fine.
So, to summarize, if I actually want to append files and have their chapters really appended correctly, I have to manually edit each original chapter edition so that they have same UID (which is not U any more?), and then append files; then it seems it works correctly.
Sorry and thanks for explanations, that was not obvious at all ^^

Mosu
18th September 2010, 22:21
Additional information: If you have a Matroska file containing chapters and split it with mkvmerge then the resulting files will all have editions with identical UIDs. Appending those files again will of course only create a single edition with all chapters in it.

If you create three separate files with e.g. simple chapter format files then all the editions will have different UIDs. At the moment mkvmerge (and by extension neither mmg) does not have a switch for forcing a single edition to be used when you append such files. I will add such an option in the near future though so that you don't have to edit the source files with the chapter editor before appending them.

LeMoi
18th September 2010, 22:26
At the moment mkvmerge (and by extension neither mmg) does not have a switch for forcing a single edition to be used when you append such files. I will add such an option in the near future though so that you don't have to edit the source files with the chapter editor before appending them.That would be really great ! Thanks in advance for this feature

Mosu
19th September 2010, 22:59
Here's a build that always merges chapter editions when appending Matroska files. I decided against creating a specific option to enable the behaviour. I haven't even added an option to disable it. The reason is that I don't think anyone would need the old behaviour anyway. If someone does (and has a good example/reason for it) then I'll add an option to turn it off.

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.3.0-build20100919-309-setup.exe

hubblec4
25th September 2010, 14:26
Hi Mosu

Can you have a look to add the Subtitle.sup-format of normal DVDs?(not Bluray.sup) I have extracted the Subtitles of a DVD as SUP-files (Vobsub: VSRip doesnt work correctly for this DVDs)

hubble

Mosu
25th September 2010, 14:36
Not interested at the moment, sorry. My guess is that there are tools that can convert that format to something else.

Thunderbolt8
26th September 2010, 19:27
is there a special reason why it doesnt seem to be possible to use sings like '&' in (.xml) name tags?

Mosu
26th September 2010, 19:40
"&" is a special char in XML (same as in HTML). You have to use "&amp;" instead. Other special chars include "<" ("&lt;"), ">" ("&gt;") and " itself ("&quot;").

This is standard XML.

GodofaGap
26th September 2010, 19:55
Hi Mosu

Can you have a look to add the Subtitle.sup-format of normal DVDs?(not Bluray.sup) I have extracted the Subtitles of a DVD as SUP-files (Vobsub: VSRip doesnt work correctly for this DVDs)
Subtitlecreator can convert sup to idx/sub.

http://sourceforge.net/projects/subtitlecreator/files/

(download the Setup_SubtitleCreator_v2_3rc1.exe file)

stax76
26th September 2010, 20:00
@hubblec4

When things fail you can always fix things with ProjectX or better rip with MakeMKV, probably best ripping method anyway.

LeMoi
26th September 2010, 23:20
Here's a build that always merges chapter editions when appending Matroska files. I decided against creating a specific option to enable the behaviour. I haven't even added an option to disable it. The reason is that I don't think anyone would need the old behaviour anyway. If someone does (and has a good example/reason for it) then I'll add an option to turn it off.

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-4.3.0-build20100919-309-setup.exe
Works fine, thanks again !

madshi
27th September 2010, 15:57
@Mosu, I've a very small problem with the header compression thingy. Generally, it works fine. However, due to how the processing classes are structured in my software (e.g. eac3to), every time header compression is used, I have to reallocate every video and audio frame twice (can't change that). So my wish is this: Could you disable header compression by default for video tracks, if the savings is <= 1 byte? If the savings is 2 byte or more, fine. But with 1 byte savings for video tracks, the size gain is really incredibly small, and not worth the processing performance penalty - for me at least. The situation is a little different for audio tracks, because there the frames are much smaller, so the space saving (in percent) is bigger and the reallocation + memory MOV less costly.

Anyway, this is just a little wish, I can live with the status quo.

Mosu
27th September 2010, 16:02
One of the reasons I don't change the default option is that I refuse to make mkvmerge pay attention to each and every other Matroska processor out there. That would be a losing battle, and mkvmerge would always only cater to the least common denominator. Your program has a problem with feature X. That other program has a problem with feature Y. And yet another device doesn't like Z. Maybe what they don't like even contradicts itself. So my choice is to make the specs the thing I base mkvmerge's defaults and output on. Because ultimately that's the only sane thing to do.

It boils down to, you guessed it already: sorry, but no.

madshi
27th September 2010, 16:26
Ok with me. My software works just fine with mkvtoolnix as it is.

I was just saying that IMHO 1 byte savings per video frame is not worth the added complication (and CPU penalty) of header compression. Using header compression just because you *can* use it is IMHO a doubtful concept. I think a feature which makes things more complicated and processing intense should only be used if it's really worth it. The specs don't say you *should* use header compression, they just say that you can. The specs allow you to do a lot of funny things that don't always make sense, but that doesn't mean you should actually use every one of these things all the time. But that's just my personal opinion, of course. I understand that your opinion is different.

MrVideo
28th September 2010, 03:55
The specs don't say you *should* use header compression, they just say that you can. The specs allow you to do a lot of funny things that don't always make sense, but that doesn't mean you should actually use every one of these things all the time. But that's just my personal opinion, of course. I understand that your opinion is different.

Your opinion regarding the compression is felt by a lot of users, developers, etc. You are absolutely correct, just because the spec supports header compression, and because the spec does not say that header compression must be used, is no reason to use it and force everyone out there to find out that they don't support it.

Personal Opinion Mode = ON

To me, that is being a little arrogant. It is up to the owners of the specification to decide if they'll force the issue. It seems that they haven't, yet Mosu is. To add insult to injury, he refuses to add a configurable option that allows the ability to have it on, or off, by default. Instead, those using the GUI must make a few menu selections to kill the compression for each and every job being done. It is easily forgotten. Then the job must be redone. This has frustrated many a user.

Yes, Mosu have the right to do whatever he wants with his program. There is no denying that fact. But, I think that consideration should be given to the community at large. Why now, after all this time. And, as you point out, there is no savings in either the file size or required processing power.

Personal Opinion Mode = OFF

I'll go back under my rock now.

burfadel
29th September 2010, 17:54
Is there any reason why the the latest download build at http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/ is lower than the previous build, having the same build number as the one two builds before it?
mkvtoolnix-unicode-4.3.0-build20100919-307-setup.exe
mkvtoolnix-unicode-4.3.0-build20100919-307.7z
mkvtoolnix-unicode-4.3.0-build20100919-309-setup.exe
mkvtoolnix-unicode-4.3.0-build20100919-309.7z
mkvtoolnix-unicode-4.3.0-build20100928-307-setup.exe
mkvtoolnix-unicode-4.3.0-build20100928-307.7z

Mosu
29th September 2010, 18:02
Server crash on my build server. I had to restore from backups, and it looks like there have been builds since that backup was made. I'll increment the file manually and create a new build so that there's no confusion.

Mosu
29th September 2010, 18:07
Done. The newest build has number 311: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/

mmiii
5th October 2010, 22:27
Hi,

sorry I´m new on this.
I´ve merged two MKV which had thubnails in W7 explorer.
After the merge the mkv file has lost the preview thumbnail.

Any ideas to solve the problem.
I´m using 4.3.0

Thanks

Superb
5th October 2010, 22:44
Hi,

sorry I´m new on this.
I´ve merged two MKV which had thubnails in W7 explorer.
After the merge the mkv file has lost the preview thumbnail.

Any ideas to solve the problem.
I´m using 4.3.0

ThanksYou probably see thumbnails because you have DivX installed.
AFAIK, the DivX thumbnail source doesn't support streams compression, so that might be the issue.
Simply remux w/ the compression off.

mmiii
5th October 2010, 22:54
Hi,
:thanks:for the help.
I'm embarrassed :o but I do not know where I can set this.
Do I need to activate this already when I create the MKV (h264/AVC with Super (C)?
Or can I disable the compression at mkvmerge?

Thanks

mmiii

mmiii
5th October 2010, 23:03
ok, I found the compression flag, if I activate the Video Stream.
But patently I have to select it individually for each stream. Is there a chance to set it globaly ?
Thumbnail is shown :-)

mmiii

73ChargerFan
6th October 2010, 15:20
:( Sorry, no

MrVideo
11th October 2010, 04:24
Is there a chance to set it globaly?

As indicated, the answer is no. The logic behind Mosu's reasoning has baffled many.

Go back through the postings to try to get a handle on the situation.

|nvari
14th October 2010, 16:47
@Mosu - is there a way to add an Intro before the movie (like a DVD) or a watermark ?

thanx