mkvtoolnix 4.1.1 released

[Mosu]

I've used Matroska to store my TV captures mainly because your GUI is so easy to use and has worked very well. Big thanks for providing it.:thanks:

However I hope that you could revise your stance about demuxing because I would feel much more safer if I could later get streams out for possible re-encoding.

Like sneaker_ger said, there are possibilities. And the fact that you can watch the files means that there are even more ways to demux stuff, just not with mkvextract.

One problem and the foremost reason why I won't implement this in mkvextract itself is that files without a default duration most often do not have a fixed frame rate. Such video tracks cannot be put into AVI files without them getting all wrong regarding A/V sync. A possiblity would be to "extract" them into MP4 files instead because MP4 files don't need a fixed frame rate. That however would require tons of work because mkvextract doesn't have a MP4 muxer built in, and even though there are libraries that make this easier this is waaaaaaaaaaay more work than I'm willing to spend on such a feature.

[avivahl]

What about extracting the raw streams (separated) each to its own raw file? (instead "to a different container)
Does mkvextract supports that?

[VHT]

Hi,i've got a strange problem with mkvmerge. I currently use lg-bd390 blu-ray player to watch my mkv muxed movies.Audio and video runs just smooth when I mux raw h.264 stream and raw DTS stream into mkv with mkvmergeGUI. Yesterday I noticed that if I open the mkv movie I've created from raw streams with mkvmerge and mux it again (and add subs or add nothing) i get drops in audio that lasts less than a half second.Using the same method with DD audio, i get no problems.Any ideas?

[sneaker_ger]

What about extracting the raw streams (separated) each to its own raw file? (instead "to a different container)
Does mkvextract supports that?

It's possible. Use the switches "--raw" or "--fullraw". See the documentation (http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvextract.html) for more info.

[b66pak]

One problem and the foremost reason why I won't implement this in mkvextract itself is that files without a default duration most often do not have a fixed frame rate. Such video tracks cannot be put into AVI files without them getting all wrong regarding A/V sync.

don't we have already TimeCodes for this kind of situations?
_

P.S. @sneaker_ger thanks for the tip!
_

[WillKane]

Sorry but I misunderstood that mkvextract would be abandoned altogether. It makes much sense that mkvextract doesn't write to AVI without default frame duration. When I mux M2V files default duration is written to file as before.

[Isochroma]

So MKVextract's gonna be toast, eh?

[Mosu]

Huh? No one said that. I was talking about this one particular type of video codec with that certain problem of not having a default duration field. However, mkvextract has never been my highest priority. Priority for me is creating Matroska files, not taking them apart.

[roozhou]

here are some .mp4 that i converted to .mkv (using mkvtoolnix-unicode-2.9.8-build20091120-180)...the resulted .mkv's can't be demuxed by mkvextract!

http://www.mediafire.com/?gwywzimomqx
_

Try my ffmpeg build to remux mkv to mp4. Don't use official ffmpeg build. They won't work on mkv.

https://sourceforge.net/projects/direct264/files/Related%20Programs/ffmpeg%20%28demuxer_muxer%20only%29/ffmpeg_svn_r20373.7z/download

[b66pak]

@ roozhou thanks...
_

[Keiyakusha]

Mosu
Hi! When I'm trying to append 2 raw h264 streams, after setting FPS for the first stream there is no way to set it for second one , but if I try to mux it, the message still appears and asks me to set FPS... Is it possible to fix this?

By the way, why all settings for appended stream becames grayed out? Its should be possible to have second segment with different fps/dar/something else... or no?

[Mosu]

Mosu
Hi! When I'm trying to append 2 raw h264 streams, after setting FPS for the first stream there is no way to set it for second one , but if I try to mux it, the message still appears and asks me to set FPS... Is it possible to fix this?

This has already been fixed in one of the latest builds available at http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/

By the way, why all settings for appended stream becames grayed out? Its should be possible to have second segment with different fps/dar/something else... or no?

Most settings directly influence the track headers, and therefore only the first track in an append chain may have those set. It's pretty much the same for FPS; mkvmerge also doesn't support changing the FPS for appended tracks.

To make this clearer: Appending two tracks results in a single track in the output file. This single track only has one copy of its headers, obviously, therefore most settings cannot be changed and therefore most stream parameters (private data, pixel width/height etc) must match in the first place or mkvmerge will not allow you to append them.

[Mosu]

Hey,

I've released mkvtoolnix v2.9.9. This release contains contains the usual mix of bug fixes and smaller enhancements. Nothing overly exciting to mention, I guess. I also started providing binary packages for OpenSuSE 11.3 and Ubuntu 9.10 Karmic Koala (both 32bit and 64bit).

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-2.9.9.tar.bz2

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

All binaries that I provide myself have already been uploaded.

Here's the full ChangeLog since release 2.9.8:

------------------------------------------------------------
2009-11-25 Moritz Bunkus <moritz@bunkus.org>
* Released v2.9.9.

2009-11-11 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: The warning that no FPS has been entered for AVC/h.264 elementary streams is not shown anymore for appended tracks (only once for the first track that they're appended to).

2009-10-25 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The pixel cropping parameters were not kept when muxing from Matroska files.
* mkvmerge: bug fix: The display width/height parameters were not kept when muxing from Matroska files if the bitstream of the track contained different aspect ratio information. Now the order is "command line" first, "source container" second and "bitstream" first.

2009-09-04 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed the subtitle track selection for AVI files.

2009-08-23 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: A single '+' causes the next file to be appended just like putting the '+' in front of the file name.

2009-08-21 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The integrated help ('--help') contained wrong information about the '--sync' option. Fix for bug 435.

2009-08-18 Moritz Bunkus <moritz@bunkus.org>
* mmg: enhancement: The file dialogs for 'add file'/'append file' will show files with extensions in all uppercase as well. This only applies to file systems that distinguish between case (e.g. most of the non-Windows, non-FAT world). Fix for bug 433.

2009-08-16 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Missing ChapterLanguage elements were assumed to be set to "und". They're now assumed to be "eng" in accordance with the Matroska specifications.
* Added a new program 'mkvpropedit' that can modify certain properties of existing Matroska files. It is mmg's header editor, just for the command line.
------------------------------------------------------------

Have fun.

[J_Darnley]

Nice work. One small issue with the changelog: 'Now the order is "command line" first, "source container" second and "bitstream" first.' You have said first twice, should that be '"bitstream" last'?

[Mosu]

Yes, it should.

[WantStuff]

Wow. Just downloaded 2.9.9 and the first thing I used was the header editor, it's really quick now!
A massive performance gain. Well done.

A feature I would love now is a CLI version of the header editor... any chance?

[Mosu]

Quoting myself here:

2009-08-16 Moritz Bunkus <moritz@bunkus.org>
* Added a new program 'mkvpropedit' that can modify certain properties of existing Matroska files. It is mmg's header editor, just for the command line.


That program is part of all binary packages (Linux, Windows) and will be compiled if you compile mkvtoolnix yourself without the need for further configuration/special options.

[WantStuff]

Damn you're quick, excellent service!

Yes sorry, I should have read it properly. I guess I was caught up in the moment...

[Mosu]

No problem :)

[MatLz]

Hi Mosu!
Why when I precise the fps of an avc stream to 23.976 the resulting mkv is 24000/1001 fps?
I must precise a fraction like 23976/1000 or 2997/125 to get 23.976fps.

[nurbs]

I assume it's because normally people use 23.976 as a short form for when they mean 24000/1001. Personally I've never seen a source that is really 23.976, they are all 24000/1001 (Blu-Ray, HD-DVD, NTSC DVD).

[Mosu]

nurbs' description is spot on. Way back in the day users requested that the values 23.976 and 29.97 are treated as 24000/1001 and 30000/1001 respectively.

[Abradoks]

mkvtoolnix recognises MP3 in WAV container as PCM. Not a big problem, but thought I should report it.

[Mosu]

Will not be fixed.

[Snowknight26]

Is it possible to mention the offset (in bytes perhaps) as to when a track contains bad data? I captured some video that happened to have corruption in it, so when I went to remux it to MKV with mkvmerge, it spat out an error along the lines of 'the AC3 track contained 1536 bytes of malformed packets, a/v synchronization may be lost.' It'd be nice to know where that happens so I can further investigate.

[Mosu]

It is technically possible, but it requires some work because neither of those packetizers (MP3, AAC, AC3) keeps track of the current stream position. So not in the near future.

[Keiyakusha]

Hi, Mosu. I want to ask something about how Display width/height in matroska meant to be handled...
Something like splitter tells exact resolution to the player and player do some scaling to accomplish this? So if original resolution is 640x360 and Display width/height is 1280x720, I should not be able to tell if the video is scaled from 360p on the fly or before encoding unless I look to some statistics?
If this is so, does haali splitter respects that?

[Mosu]

Hi, Mosu. I want to ask something about how Display width/height in matroska meant to be handled...
Something like splitter tells exact resolution to the player and player do some scaling to accomplish this? So if original resolution is 640x360 and Display width/height is 1280x720, I should not be able to tell if the video is scaled from 360p on the fly or before encoding unless I look to some statistics?

The idea is indeed that the initial size of the video during playback is set to display width/height by the player (not the demuxer or codec though -- it is supposed to be up to the player so that the user still has the choice which scaling methods to use etc). It is not supposed to be a fixed size so the user should still be able to resize the playback window afterwards.

However, most players if not all only use the quotient "display_widht/display_height" as the aspect ratio for playback and determine the initial size themselves. Some muxing applications or users of those even go so far and use e.g. "16" for the display_width and "9" for the display_height parameter -- but this is mostly a result of the players not honoring the actual display width/height but only using its quotient for aspect ratio calculation.

If this is so, does haali splitter respects that?

I don't know, and like I said, it is supposed to be the player's job, not the splitter's/demuxer's/codec's. However, I'm not familiar with Windows' multimedia stack and cannot judge whether or not it would be easier to implement proper display width/height handling in the splitter itself.

[Keiyakusha]

Mosu
Thank you! :goodpost:

[WestFlame]

Hi, I would like to ask if there will be any “Tag Editor” for Matroska files like the Chaper one in mmg?

Thanks.

[Mosu]

Maybe, maybe not.

[Chumbo]

Mosu,
I have a stream where the audio is 1 second behind the video. Rather than chopping off the first 1024ms of the audio, I decided to use a delay of +1024 on the video track but it made no difference in the resulting file. Using -1024 on the audio track works just fine. Not sure if the delay for the video track is supposed to work or not or if it ever did, but wanted to let you know that it does not work. At least not in 2.9.9.

[Mosu]

Have you made sure with mkvinfo that the video track timestamps are REALLY not adjusted by that 1024? Because it's working just fine for me:

[0 mosu@tionne ~/prog/video/mkvtoolnix/data] mkvmerge -i v.avi
File 'v.avi': container: AVI
Track ID 0: video (DIV3)
Track ID 1: audio (MP3)
[0 mosu@tionne ~/prog/video/mkvtoolnix/data] mkvmerge -o v.mkv --sync 0:1000 v.avi
mkvmerge v2.9.9 ('Tutu') built on Dec 5 2009 19:04:14
'v.avi': Using the AVI demultiplexer. Opening file. This may take some time depending on the file's size.
'v.avi' track 0: Using the video output module.
'v.avi' track 1: Using the MPEG audio output module.
The file 'v.mkv' has been opened for writing.
Progress: 100%
The cue entries (the index) are being written...
Muxing took 0 seconds.
[0 mosu@tionne ~/prog/video/mkvtoolnix/data] mkvinfo -s v.mkv | grep -i 'track 1' | head -n 2
Track 1: video, codec ID: V_MS/VFW/FOURCC (FourCC: DIV3, 0x33564944), default duration: 41.708ms (23.976 fps for a video track), language: und, pixel width: 640, pixel height: 352, display width: 640, display height: 352
I frame, track 1, timecode 1000 (00:00:01.000), size 13424, adler 0x6e3488a8


I can see two possiblities:

1. Your command line is wrong. This could even be the case if you're using mmg; though in that case it would obviously be a bug in mmg.

2. The process is working fine, but playback doesn't honor that 1s offset. In this case there's nothing I can do about it.

[burfadel]

I was wondering whether a batch remux facility could be incorporated in to mmg. An example would be to click on remux, select 'add files' where you can select all acceptable containers currently, and then proceed and it automatically convert the avi and mp4 container input files to mkv. Even handier would be the ability to select files, and subfolders where you may have tv shows, and be able to output the files with the same folder structure. In the next month or so, I will be transferring files to new hdd's, so thought it would be good to standardise my video content in terms of container format. The ability to do subfolders etc would be handy, so I could essentially just select the main video folder on the old 750gb drives, and output the main folder on the new drives keeping the current folder structure.

MMG is an excellent muxer, I'm sure a batch remux function as outlined above wouldn't be too difficult to implement and I'm sure many would find it useful.

[Mosu]

Sorry, but such a feature will never be implemented. There are excellent shells out there that can do this easily. For example, with a bash you could convert all .avi files into Matroska with these commands:

find -type f -name '*.avi' | { while read filename ; do mkvmerge -o /path/to/output/dir/"`basename "$filename" .avi`.mkv" "$filename" ; done ; }

I know that using shells is not everyone's thing. However, implementing a powerful and flexible batch remuxer requires countless hours of work. If I cut down on the hours then either the flexibility or the number of features would be severely reduced and therefore the work would not be worth it because too few people could actually use it in such a state.

The short version is that it's waaaaay too much work and that I don't have that amount of free time. So.... no. Sorry.

[burfadel]

Ah ok! I didn't realise it would be such a complex thing :) lol

[thymej]

mmg sees the first DVD movie vob, vts_0x_0.vob with a mpeg2 video and ac3 audio as it should, but all the other vobs part of the dvd movie are seen with an AVC/h.264 video with ac3 audio. So I cant append the vobs together on a dvd, to make a mkv.

tsRMuxer, MediaInfo all see the vobs with mpeg2 video, only mmg sees only the first vob with mepg2 video. Does this mean its not supported and I have to use a 3rd party vob joiner first?

[Chumbo]

Have you made sure with mkvinfo that the video track timestamps are REALLY not adjusted by that 1024? Because it's working just fine for me:



I can see two possiblities:

1. Your command line is wrong. This could even be the case if you're using mmg; though in that case it would obviously be a bug in mmg.

2. The process is working fine, but playback doesn't honor that 1s offset. In this case there's nothing I can do about it.
I'll have to use mkvinfo to check what you suggested, so no I have not done that.

In regards to the two possibilities: #1) I used the UI so I assume the command it executes is fine and #2) You may be correct in this.

I'll grab mkvinfo and check it out. Thank you.

[Mosu]

mmg sees the first DVD movie vob, vts_0x_0.vob with a mpeg2 video and ac3 audio as it should, but all the other vobs part of the dvd movie are seen with an AVC/h.264 video with ac3 audio. So I cant append the vobs together on a dvd, to make a mkv.

That's a known problem that I haven't had the time to look at yet. See also https://www.bunkus.org/bugzilla/show_bug.cgi?id=437

Does this mean its not supported and I have to use a 3rd party vob joiner first?

"Well... it's kinda supposed to work" to the first question and "that'd be the best workaround to use for the time being" to the second one.

[Snowknight26]

Apparently if you Alt+F4 the muxing progress window, the muxing still continues in the background.

[Mosu]

Use the "Cancel" button instead. I won't fix that.

[osgZach]

The header editor is a pretty nice tool, although I was wondering if there are other tools out there that might allow batch modifications of specific tags by specific criterea ? I tried messing with the CLI but I ended up feeling overwhelmed real fast and worried I was gonna screw up the file somehow.

e.g Process 10 files, and set all tracks with tag value of "X" to the default playback track, and any other languages to "not default". It seems I've messed up some of my stuff in the past, would be nice to fix without a remux.

Also.. keeping that in mind, I think my WDTV Live doesn't even recognize the default playback tag (I haven't tested it for sure), I'm not sure.. It may be going by the first audio track it finds - is there a way I can re-assign track numbers without remuxing ? Or for that matter editing or adding new chapters?

I'm guessing its probably just easier to demux and remux though..

[Mosu]

The header editor is a pretty nice tool, although I was wondering if there are other tools out there that might allow batch modifications of specific tags by specific criterea ? I tried messing with the CLI but I ended up feeling overwhelmed real fast and worried I was gonna screw up the file somehow.

Not in that detail, but there's mkvpropedit which is like mmg's header editor just for the command line. And it is as it is with the command line -- there's no tool more powerful if you know how to use it :)

e.g Process 10 files, and set all tracks with tag value of "X" to the default playback track, and any other languages to "not default". It seems I've messed up some of my stuff in the past, would be nice to fix without a remux.

Easily scriptable with a proper shell (e.g. bash), analyzing the output of "mkvmerge --identify ..." and calling mkvpropedit with the appropriate parameters.

It may be going by the first audio track it finds - is there a way I can re-assign track numbers without remuxing ?

You can do that with mmg's header editor and with mkvpropedit.

[osgZach]

Well like I said, I tried using the CLI but just found it a little over my head I think. Perhaps I'll give it another go, if there are any in-depth guides to using it (besides the documentation) maybe that would help me get the hang of it a little more.

I was planning to just write a batch file to do a bunch of CLI stuff, just having trouble getting to hang of the mkvpropedit tool I guess.

[Mosu]

Hey,

I've released mkvtoolnix v3.0.0. This release contains contains the
usual mix of bug fixes and smaller enhancements.

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-3.0.0.tar.bz2

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

All binaries that I provide myself have already been uploaded.

Here's the full ChangeLog since release 2.9.9:

------------------------------------------------------------
2009-12-12 Moritz Bunkus <moritz@bunkus.org>
* Released v3.0.0.
* mmg: enhancement: Added support for showing the muxing progress for both normal muxes and the job manager in Windows 7's taskbar.

2009-12-06 Moritz Bunkus <moritz@bunkus.org>
* all: bug fix: The charset for output in cmd.exe for non-English interface languages has been fixed on Windows Vista and Windows 7.
* all: enhancement for Windows platforms: If one of the mkvtoolnix components is run without having been installed before then translations will be read from the directory the .exe is run from.

2009-12-05 Moritz Bunkus <moritz@bunkus.org>
* configure: Added an option ('--without-build-timestamp') that omits the build timestamp from all version information so that two builds of mkvtoolnix can be byte-identical.

2009-12-04 Moritz Bunkus <moritz@bunkus.org>
* mkvpropedit, mmg: bug fix: Editing headers of files created by HandBrake would cause crashes and/or corrupted files after saving. Fix for bug 445.
------------------------------------------------------------

Have fun.

Mosu

[Chumbo]

Congrats on the new major version release Mosu. Thank you for your continued efforts on this tool. I, for one, really appreciate it.

[sneaker_ger]

Thx for the release. Any news on bug 289?

[stax76]

Congrats Mosu on the major release and thanks for everything.

[Snowknight26]

The output text box's text isn't vetically centered properly due to the text box being taller than usual.

[Mosu]

Congrats on the new major version release Mosu. Thank you for your continued efforts on this tool. I, for one, really appreciate it.

Thanks & you're welcome :)

Thx for the release. Any news on bug 289?

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.

Congrats Mosu on the major release and thanks for everything.

Thanks & you're welcome :)

The output text box's text isn't vetically centered properly due to the text box being taller than usual.

The text is not supposed to be centered.