mkvtoolnix 4.1.1 released [Archive]

Mosu

13th January 2007, 20:28

Current version is 4.1.1; see http://forum.doom9.org/showthread.php?p=1414216#post1414216

--------------------------------------------------------------------

Hey users,

I'm proud to present you version 2.0.0 of mkvtoolnix. This release contains new features like support for AVC/h.264 elementary streams (both single files and from AVIs); proper support for MPEG-1/-2 videos without the ugly blockiness; support for extracting MPEG-1/-2 video tracks; use of "simple blocks" with subtitles has been fixed; tons of usability enhancements to mmg; and the usual list of smaller bug fixes.

A special "thanks" to all the people who extensively tested my h.264 support and provided a lot of insight and sample files.

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

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

...the Windows binaries (2000/XP or later):
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-2.0.0-setup.exe

The binaries for the various Linux versions that I provide have already been updated and are available from the download page: http://www.bunkus.org/videotools/mkvtoolnix/downloads.html

Here's the ChangeLog since 1.8.1:

------------------------------------------------------------------
2007-01-12 Moritz Bunkus <moritz@bunkus.org>
* mmg: new feature: Added another tab for each track in which the user can add arbitrary track options.
* mkvextract: enhancement: mkvextract will now also print which container format it uses for each track.
* mkvextract: new feature: Added support for extracting MPEG-1/2 video to MPEG-1/2 program streams.
* mkvmerge: bug fix: Fixed the file type detection for MPEG-1/2 ES files with a single frame inside.

2007-01-11 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: MPEG-1/2 video: The sequence and GOP headers are not removed from the bitstream anymore. This should fix the blockiness if the sequence headers change mid-stream. Fix for Bugzilla bug #167.

2007-01-09 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: mkvmerge now handles the first frames in AVC/h.264 ES streams properly, especially for files for which it did not find a key frame at the beginning in earlier versions.

2007-01-08 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: Improved the detection of AVC/h.264 ES streams with garbage at the beginning.
* mmg: enhancements to the job management dialog: There's a minimum width for the columns. The "up" and "down" buttons are disabled if all entries are selected. Pressing "Ctrl-A" selects all entries.
* mmg: enhancements: "File -> New" will also focus the "input" tab.

2007-01-07 Moritz Bunkus <moritz@bunkus.org>
* mmg: enhancements: The job manager can be opened with "Ctrl-J". The last directory from which a file is added is saved even if the file identification failed. The automatically generated output file name uses the extension ".mka" if no video track is found and ".mks" if neither a video nor an audio track is found in the first file.
* mkvmerge: bug fix: Fixed the aspect ratio extraction for raw AVC/h.264 ES tracks.
* mkvmerge: bug fix: If a raw AVC/h.264 ES file does not start with a key frame then all the frames before the first key frame are skipped, and mkvmerge does not abort anymore.

2007-01-05 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: AVC/h.264 ES parser: Fixed wrong NALU size length information in the AVCC.
* mkvmerge: bug fix: AVC/h.264 ES parser: Fixed the decision if a NALU belongs to a previous frame or starts a new one.

2007-01-04 Moritz Bunkus <moritz@bunkus.org>
* mmg: enhancement: Added an input for the new "NALU size length" parameter.
* mkvmerge: bug fix: The NALU size length can be overridden for AVC/h.264 elementary streams. It defaults to 2 which might not be enough for larger frames/slices.

2007-01-03 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Support for AVC/h.264 elementary streams with short markers (0x00 0x00 0x01 instead of 0x00 0x00 0x00 0x01).
* mkvmerge: Removed the "--engage allow_avc_in_vfw_mode" hack.
* mkvmerge: enhancement: Added "x264" to the list of recognized FourCCs for AVC/h.264 video in AVI and Matroska files.
* mkvmerge: new feature: Added support for proper muxing of AVC/h.264 tracks in Matroska files that were stored in the MS compatibility mode (CodecID V_MS/VFW/FOURCC instead of V_MPEG4/ISO/AVC).
* mkvmerge: bug fix: Fixed invalid memory access in the AVC ES parser.

2007-01-02 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Added support for proper muxing of AVC/h.264 tracks in AVI files.

2007-01-01 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Added support for reading AVC/h.264 elementary streams.

2006-12-30 Moritz Bunkus <moritz@bunkus.org>
* mmg: enhancement: All inputs and controls are cleared and deactivated if the user select "File -> New".
* mmg: enhancement: The user can switch between the "generic" and "format specific options" pages even if no track is selected.

2006-12-29 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: mkvmerge would not write frame durations if "--engage use_simpleblock" was used resulting in unplayable and unextractable subtitle tracks.

2006-12-28 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Added a workaround for RealAudio tracks for which the key frame flag is never set.

2006-12-27 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Fixed a segfault that occured if the user had a track selected and its the file the track was read from is removed.
* mmg: bug fix: Fixed the behaviour of a couple of ComboBoxes on Windows after selecting "File -> New". E.g. if the user selected "700M" in the "split after this size" ComboBox, selected "File -> New" and selected "700M" again, then it would not show up in the command line window until he selected another option and returned to the "700M" afterwards.
------------------------------------------------------------------

Have a nice weekend :)

Regards,
Mosu

shon3i

13th January 2007, 21:55

Nice, thanks for hard work

HeadBangeR77

13th January 2007, 23:55

That's good news :) Much appreciated!

buzzqw

14th January 2007, 01:29

that's awesome ! thanks !!!

BHH

Sharktooth

14th January 2007, 05:09

linux version works perfectly, thanks ;)

LeMoi

14th January 2007, 17:19

If i'm on Global Settings Tab and and make a new muxing (via ctrl+n), mmg gets back to Input Tab :(

Eragon4ever

14th January 2007, 17:29

* mmg: enhancements: "File -> New" will also focus the "input" tab.

This feature was requested by me. I set the options on the Global tab always after I load a file and don't see the sense in doing it the other way.
Why do you prefere the old behavior?

Regards,
LaughingMan ;-)

LeMoi

14th January 2007, 17:56

Because sometimes i mux series of files with same prefix ; for example i mux with title : "Name of show - SXXEXX - title of episode", and after muxing, when i want to mux next episode, instead of typing again "Name of show - SXXEXX+1 - title of episode", i copy it before making new mux, then paste it into new mux, thus it's easyier to stay in Global Settings instead of getting back to Input, then Global Settings
I don't know if i'm clear :D

Eragon4ever

14th January 2007, 18:05

Got it (and doing it myself sometimes:p ).
However you still have to load the next file (or did I miss something?) so you could copy the title, load the next file etc. and THEN paste and mux.

Mosu

14th January 2007, 18:05

I can make it optional. Hmm, I think it's time to move the "settings" tab to its own window :)

guada2

14th January 2007, 21:53

great work Mosu.
Bye ;)

madshi

15th January 2007, 09:46

The new version is much appreciated!

:thanks:

Isochroma

15th January 2007, 10:04

Your work continues to be invaluable to the video community, so a heatfelt thank you!

I've been playing with demuxing EVOBs (http://forum.doom9.org/showthread.php?p=935396#post935396) recently (they're enhanced VOBs), and had the opportunity to test AVC-ES muxing in 2.0.0.

Now, I've already tested it on more generic AVC-in-AVI streams and it's worked fine, however...

Using Graphedit, I've been able to get a very wild & wooly .264 file from an EVOB. MKVToolnix muxes it with no errors, but when played the file shows bad blocking and artifacting on almost every frame.

After finding this out, I used Yamb 1.6.0 to mux to .mp4, which subsequently played just fine. Perfect results were also achieved after muxing this .mp4 into MKV with 2.0.0.

So there is some difference between your ES handling code and MP4Box's.

I can provide the raw stream, but it's 107 MB, and I don't know of any tools to cut raw .264 streams. Maybe you can suggest something?

To finish off, many new file sources in VC-1 are coming online, and so I'd like to suggest the possibility of MKVToolnix supporting VC-1 muxing.

For example, many HD-DVDs are encoded with this new codec, but often the on-disc EVOBs are too difficult for users to play due to high CPU usage, or impossible due to HDCP requirements.

Remuxing AVC from EVOB to MKV has reduced the CPU usage at least 40%, by my latest test. It was enough to make an unplayable video playable, so this excellent format will undoubtedly also make a very significant difference in VC-1 playback performance.

HeadBangeR77

15th January 2007, 11:48

Just a small question: I've recently made an encode with XviD & AC3 5.1 with VDubMod directly into *.mkv container. As an error appeared during muxing the video with audio and the whole process didn't finish I decided to mux with MKVToolnix. Out of two possible ways one worked fine and one didn't:

1) Adding the final pure-video *.mkv worked just fine. I added the audio + subs + *.xml chapters and everything was ok.

2) I also extracted the resulting video from VDubMod's mkv using AVI-Mux GUI into raw MPG-4 ASP stream. MVKToolnix didn't want to swallow it.

Don't get me wrong, it's not a problem for me, as the first way is an easier and faster solution, but just a matter of supporting such streams (for my own curiosity :p). Am I missing sth obvious? (I'm pretty unexperienced with mkv muxing) ...

LeMoi

15th January 2007, 13:14

However you still have to load the next file (or did I miss something?) so you could copy the title, load the next file etc. and THEN paste and mux.
I don't load it, i "make" it, it's a new muxing from video and audio files. But i paste then mux, i'm not on Global Settings tab any more with mmg 2.0.
Any way it's no big deal, i was just used to this feature ^^

Mosu

15th January 2007, 13:25

Using Graphedit, I've been able to get a very wild & wooly .264 file from an EVOB. MKVToolnix muxes it with no errors, but when played the file shows bad blocking and artifacting on almost every frame.

After finding this out, I used Yamb 1.6.0 to mux to .mp4, which subsequently played just fine. Perfect results were also achieved after muxing this .mp4 into MKV with 2.0.0.

So there is some difference between your ES handling code and MP4Box's.

I can provide the raw stream, but it's 107 MB, and I don't know of any tools to cut raw .264 streams. Maybe you can suggest something?

I don't know any tool for cutting, sorry. Just upload the full 107 MB :) It doesn't matter if it takes quite a while. Thanks.

To finish off, many new file sources in VC-1 are coming online, and so I'd like to suggest the possibility of MKVToolnix supporting VC-1 muxing.

I don't really know anything about VC-1 and how to parse it. And I'm still busy with other bugs/things, so I won't invest time into VC-1 right now. But I'll keep it in mind.

Mosu

15th January 2007, 13:26

2) I also extracted the resulting video from VDubMod's mkv using AVI-Mux GUI into raw MPG-4 ASP stream. MVKToolnix didn't want to swallow it.

As you've guessed mkvtoolnix does not support MPEG-4 part 2 ASP raw streams.

HeadBangeR77

15th January 2007, 13:41

As you've guessed mkvtoolnix does not support MPEG-4 part 2 ASP raw streams.
Short & clear, ta ;)

Eragon4ever

15th January 2007, 13:45

I can provide the raw stream, but it's 107 MB, and I don't know of any tools to cut raw .264 streams. Maybe you can suggest something?

I use this (http://rapidshare.com/files/11808088/Chainsaw_3.7.7z.html) (uploaded it because I don't know where to get ). It's in German but the most things should be self-explanatory. Just set the size and drag the file on the chainsaw picture. It may cut every file type because it just starts an new file after the given size.

DoctorEnsGabe

15th January 2007, 20:07

Two quick questions about mkvtoolnix 2.x:

1) Are MPEG-2 in TS files on the radar for a future version?

2) In your ubuntu repositories, why do you have a separate package 'mkvtoolnix-mb' instead of a version-bumped mkvtoolnix? The way you have it set up, your package conflicts with and removes mkvtoolnix and subsequently removes everything that depends on it, e.g. mkvtoolnix-gui. Is this just an oversight, or are there some irreconcilable differences between those two packages?

Mosu

15th January 2007, 20:36

Two quick questions about mkvtoolnix 2.x:

1) Are MPEG-2 in TS files on the radar for a future version?

Most likely not.

2) In your ubuntu repositories, why do you have a separate package 'mkvtoolnix-mb' instead of a version-bumped mkvtoolnix? The way you have it set up, your package conflicts with and removes mkvtoolnix and subsequently removes everything that depends on it, e.g. mkvtoolnix-gui. Is this just an oversight, or are there some irreconcilable differences between those two packages?

That's the intention. mkvtoolnix and mkvtoolnix-gui are the official packages in Debian and Ubuntu. My package is mkvtoolnix-mb and contains both the command line and the GUI versions. I just don't want to get in the way of the official packages.

madshi

15th January 2007, 21:12

I can provide the raw stream, but it's 107 MB, and I don't know of any tools to cut raw .264 streams. Maybe you can suggest something?
You can use a hexeditor to look for "00 00 00 01 67". Make sure that the h264 file begins with that sequence and make sure that it ends directly "before" such a sequence. Then you should have a good and clean cut.

HyperDrive

16th January 2007, 02:11

Just tested mkvmerge 2.0.0. The subtitles with short blocks problem I mentioned in this thread (http://forum.doom9.org/showthread.php?t=120179) is apparently corrected. Thank you very much for this new version! :)

yonta

16th January 2007, 13:26

problem with muxing MPEG4 AVC ES into .mkv. mkvmerge GUI muxes it fine but no player that I have can play the muxed file. I tried VLC, MPC, Mplayer, and plain old windows built-in mplayer2 with haali's splitter and ffdshow, all players just play audio only. If I mux the same source ES first into .mp4 with mp4box then .mkv with mkvmerge GUI, it plays just fine.

Eragon4ever

16th January 2007, 13:31

Mosu

16th January 2007, 14:01

Isochroma uploaded a file for me which seems to show exactly the behaviour you two are encountering. I'll try to fix this later this week. But if you could upload some more files to my FTP server then I'd be grateful. 10 MB or so should be enough, but you can also upload 50 MB or so.

Eragon4ever

16th January 2007, 14:30

First 20 MB of my file are on your ftp (folder: LaughingMan; name: "Elfen Lied - 01 - ...").

It muxes fine with simple block enabled, without it says the NALU size is to small.

Mosu

16th January 2007, 15:41

Please read the error message. You can and must set the NALU size manually for such files.

The only alternative would be to always use bigger NALU sizes resulting in bigger files which I don't want to do.

Eragon4ever

16th January 2007, 16:16

I read it and did as it said however BOUTH files (the one with simple block enabled and with NALU 3) don't play. I should have been more exact.

bob0r

16th January 2007, 20:47

When i open a H.264 .ts file with 2 AC3 audio tracks, only the video is added.

Is this a feature or a bug?

and an off topic question:
mplayer -dumpvideo -dumpfile raw.264 file.ts
mplayer -dumpaudio -dumpfile raw.ac3 file.ts

Doing that (those files mux perfect in .mkv now) will only extract 1 of the 2 AC3 tracks, how can i extract both?

Mosu

16th January 2007, 21:08

When i open a H.264 .ts file with 2 AC3 audio tracks, only the video is added.

Is this a feature or a bug?

Feature. Or a bug. Depends on your point of view. mkvmerge does NOT support transport streams! If it says it finds a h.264 es file then mkvmerge is mis-detecting the file, and I guess that the resulting .mkv is not playable.

and an off topic question:
mplayer -dumpvideo -dumpfile raw.264 file.ts
mplayer -dumpaudio -dumpfile raw.ac3 file.ts

Doing that (those files mux perfect in .mkv now) will only extract 1 of the 2 AC3 tracks, how can i extract both?

Try selecting a different track with -aid in the second case.

bob0r

16th January 2007, 21:20

Thanks for the quick answers, on all issues you were correct, helped a lot.

Very very sad you dont support .ts to .mkv directly, it would be the most perfect way to store satellite captures.
.ts to .mkv (if http://rickman.ri.funpic.de/ can calculate the audio delay, than so can you), then deselect any unwanted audio track, or all, and mux DD or DTS with the Video.

Cut the perfect end result file (who needs credits?), save some space on your HDD..... man i wish i never wake up.

Mosu

16th January 2007, 21:33

This build should fix the issues that Isochroma, yonta and Eragon4ever have experienced: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.0.0-build20070116-1.rar

Mosu

16th January 2007, 21:34

Very very sad you dont support .ts to .mkv directly, it would be the most perfect way to store satellite captures.

:) Does anyone have specs for h.264 transport streams? And just as important: lots of sample files?

bob0r

16th January 2007, 21:37

Additional it seems like who ever gave you the samples, wasn't using any of mine.
Muxing BBC-HD MBAFF raw.264 + raw.mp2 is giving glitches.
mplayer -dumpvideo -dumpfile raw.264 file.ts
mplayer -dumpaudio -dumpfile raw.mp2 file.ts

I tried on this sample: beyonce.at.the.bbc.1080mbaff.sample.ts (http://mirror01.x264.nl//public/force.php?file=./beyonce.at.the.bbc.1080mbaff.sample.ts)

I got more samples:

all 19.0 MB (19,963,908 bytes) (dd if=source.ts of=result.ts bs=188 count=106191 skip=0)

00:07 premiere.hd.ts
00:08 bbc.hd.ts
00:09 anixe.hd.ts
00:09 sky.movies.9.hd.ts
00:13 astra.hd.ts
00:14 arte.hd.ts
00:16 euro1080.hd5.ts
00:16 prosieben.hd.ts
00:17 luxe.hd.ts
00:18 hd.forum.tf1.hd.ts

~08mbit hd.forum.tf1.hd.ts
~09mbit luxe.hd.ts
~10mbit prosieben.hd.ts
~10mbit euro1080.hd5.ts
~11mbit arte.hd.ts
~12mbit astra.hd.ts
~17mbit sky.movies.9.hd.ts
~17mbit anixe.hd.ts
~19mbit bbc.hd.ts
~22mbit premiere.hd.ts

Guessed encoders:
grass valley bbc.hd.ts
grass valley euro1080.hd5.ts
tandberg anixe.hd.ts
tandberg arte.hd.ts
tandberg astra.hd.ts
tandberg luxe.hd.ts
tandberg premiere.hd.ts
tandberg prosieben.hd.ts
tandberg sky.movies.9.hd.ts
scientific atlanta hd.forum.tf1.hd.ts

grass valley, ViBE H.264: http://www.thomsongrassvalley.com/products/transmission/vibe/encoder_mpeg4_hd/
scientific atlanta, H.264: http://www.scientificatlanta.com/customers/Source/7006554.pdf
tandberg, H.264: http://www.tandberg.net/our_story/h264.jsp

I can give you a PM if you are interested in these samples.

Edit:
@Mosu guess i read your mind :p

Eragon4ever

16th January 2007, 21:46

This build should fix the issues that Isochroma, yonta and Eragon4ever have experienced: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.0.0-build20070116-1.rar

Thanks!
All my samples play fine now.

bob0r

16th January 2007, 21:58

madshi

16th January 2007, 22:09

:) Does anyone have specs for h.264 transport streams? And just as important: lots of sample files?
Are you seriously working on this? That would be lovely, of course! I've lots of h.264 transport streams. But I guess most are just the same, because they're all captured with the same software from the same TV channel.

Isochroma

16th January 2007, 22:23

Thanks to your efforts, my problem is solved also... but one more thing, the test.264 that I muxed with Yamb, I set the fps to 23.976, and when the MP4 was merged into MKV, the framerate now showed as 24...

With the new MKVMerge, muxing directly the ES and setting its framerate to 23.976, the output MKV has a framerate of 24.975025? Strange...

Audionut

17th January 2007, 04:15

Thanks Mosu.

yonta

17th January 2007, 09:03

Mosu

17th January 2007, 09:25

Are you seriously working on this? That would be lovely, of course! I've lots of h.264 transport streams. But I guess most are just the same, because they're all captured with the same software from the same TV channel.

I'm seriously considering working on it ;) Problem is that I don't have any specs so far, and it's always easier working with specs than just digging into the source code of various media players and muxing applications.

Mosu

17th January 2007, 09:26

@Mosu guess i read your mind :p

Indeed you do :) Thanks for the samples.

Mosu

17th January 2007, 10:44

but one more thing, the test.264 that I muxed with Yamb, I set the fps to 23.976, and when the MP4 was merged into MKV, the framerate now showed as 24...

I cannot reproduce that. I've done the following:

0 mosu@jaina:/ftp/.rip/mkv/bugs/225$ MP4Box test.mp4 -fps 23.976 -add test.264
...
0 mosu@jaina:/ftp/.rip/mkv/bugs/225$ mkvmerge -o test.mkv test.mp4
...
0 mosu@jaina:/ftp/.rip/mkv/bugs/225$ mkvinfo test.mkv | grep 'Default duration'
| + Default duration: 41.708ms (23.976 fps for a video track)

With the new MKVMerge, muxing directly the ES and setting its framerate to 23.976, the output MKV has a framerate of 24.975025? Strange...

Oops, my bad. For some special values (23.976 and 29.97) mkvmerge was supposed to use more exact values, and I made a typo there :) Please try this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.0.0-build20070117-1.rar

Mosu

17th January 2007, 10:53

Hey,

this is a small "poll" of sorts. It concerns mkvmerge's AVC/h.264 ES handling code. As some of you have noticed mkvmerge has a new parameter, "--nalu-size-length". A short explanation of what it does and why it is neccessary:

In MP4 and Matroska files each h.264 slice is prefixed with its size. This "NALU size" is always a fixed number of bytes long. It can be between one and four bytes, but it cannot vary inside a file. Two bytes means that each slice can be at most 65535 bytes long, three bytes allow for 16777215 bytes. mkvmerge defaults to "two bytes".

However, with HDTV content this almost always seems to be too low, and three bytes are needed. Hence mkvmerge's error message. Now I can have mkvmerge default to "three bytes" for the NALU size. But what would that mean?

Advantage: mkvmerge will no longer abort with this error message.

Disadvantage: For each slice mkvmerge will need one more byte of space. As each frame can consist of many slices (I have files with six slices per frame) this may become quite an extra overhead. For example, take a 25 FPS movie with six slices per frame and a duration of 90 minutes. This would mean that the resulting file would be 90 (minutes) * 60 (seconds per minute) * 25 (frames per second) * 6 (slices per frame) = 810000 bytes.

Another possibility would be to have mkvmerge scan the complete input file first in order to find the "optimal" value for the NALU size length. But that would, as I said, require reading the same file twice -- once for scanning, once for muxing.

So I'd like to know which option you prefer. Is it...

1. keep it like it is (default "two bytes", no scanning),
2. change it to "three bytes", no scanning or
3. implement scanning?

Thanks for the answers :)

Eragon4ever

17th January 2007, 14:07

I have a 4th possibility (I think):
Keep it as it is but if the NALU is to small try 3 bytes.

Besides, I would prefer scanning as it gives me smaller sizes in a reasonable amount of time (and the chance of using just 1 byte).

Edit: I think I found the TS specs: ISO 13818-1 (http://neuron2.net/library/mpeg2/iso13818-1.pdf)

Mosu

17th January 2007, 14:39

I have a 4th possibility (I think):
Keep it as it is but if the NALU is to small try 3 bytes.

Nah, not really. This would require either rewriting the part of the file that has already been written or to restart mkvmerge. I don't like either case very much; even though the latter is way easier to implement.

Besides, I would prefer scanning as it gives me smaller sizes in a reasonable amount of time (and the chance of using just 1 byte).

Don't underestimate the time it takes to scan a complete file. But anyway, I'll count this as a vote for "3." :)

Edit: I think I found the TS specs: ISO 13818-1 (http://neuron2.net/library/mpeg2/iso13818-1.pdf)

Cool, thanks.

Henrikx

17th January 2007, 15:29

@Mosu
Thank You ! Great Work !

madshi

17th January 2007, 16:12

So I'd like to know which option you prefer. Is it...

1. keep it like it is (default "two bytes", no scanning),
2. change it to "three bytes", no scanning or
3. implement scanning?
I vote for implementing 3 as default, as I'm running mkvmerge in batch in background, anyway, so time cost is not the most important factor for me. But if you decide to implement 3, you could still offer 1/2 as alternative options, if you think it's worth it.

Alternative: How late in the game could it happen that you find out that NALU 2 is not enough? If you can find out by scanning only the first 200 MB, that would be my most preferred option.

Mosu

17th January 2007, 17:19

Alternative: How late in the game could it happen that you find out that NALU 2 is not enough? If you can find out by scanning only the first 200 MB, that would be my most preferred option.

Worst case is that I find out with the very last slice that is read. Therefore scanning the first 200 MB should be enough for almost all files, but I don't want to rely on that too much.

Isochroma

17th January 2007, 17:55

810000 bytes is ridiculously small for an entire movie. What is that, 0.81 MB? Movies start at 700MB which would in this case be 0.12%?

For a two-CD size movie, that would be 0.06%, for a 4.7 GB video that would be 0.0172%.

So yes, make the NALU 3.

honai

17th January 2007, 18:01

Same here. The overhead of MKV is already very small compared to other containers, so I'm sure we can afford those 810K.

madshi

17th January 2007, 20:01

810000 bytes is ridiculously small for an entire movie. What is that, 0.81 MB?
I change my vote to "always 3 byte". When I originally read that 810000 number I was mistakingly thinking of 810 MB, which would have been too much. But 0.81 MB is really too small to worry about.

Eragon4ever

17th January 2007, 20:08

What is that, 0.81 MB?
Actually it's just 0,77MB. Just to clear that up.
OK, I'm fine with "2." if the option to set it manually stays.

Mosu

17th January 2007, 20:30

OK, I'm fine with "2." if the option to set it manually stays.

The option will definitely stay. If I change it to 3 then I'll also add a message at the end of the muxing if 2 would have sufficed -- so that people who really want the smallest possible size know that they can lower the overhead :)

bob0r

18th January 2007, 01:17

Haali

18th January 2007, 01:20

Btw, nalu size lentgh of 3 is illegal according to std, and qt decoder doesn't accept such length. Valid values are 1,2,4.

Mosu

18th January 2007, 09:05

Btw, nalu size lentgh of 3 is illegal according to std, and qt decoder doesn't accept such length. Valid values are 1,2,4.

Ah crap. This reaaaaaally makes sense... So the question is: change to 4 as the default or not?

BTW: The source code of your muxer you gave me quite a while ago used 3 as the default. I guess you've changed that by now. And MP4Box allows and uses 3, too.

Mosu

18th January 2007, 10:02

beyonce.at.the.bbc.1080mbaff.sample.ts
47.6 MB (49,999,916 bytes)
demuxed .h264 and .mp2 muxed into .mkv works

beyonce.at.the.bbc.1080mbaff.ts
4.19 GB (4,504,797,720 bytes)
demuxed .h264 and .mp2 muxing into .mkv fails.
BBC HD uses H.264 MBAFF video coding.
Also other big captures from BBC-HD fail, this error:

'die' called: common.cpp/saferealloc() called from file src/common/common_memory.cpp, line 33: realloc() returned NULL for a size of 124253 bytes.

Any chance you could find a smaller piece of that file for which mkvmerge crashes? If not, would you be willing to upload it to my FTP server? I do have the space and the bandwidth, so it'd be no problem for me.

foxyshadis

18th January 2007, 10:28

For x264 and Ateme, it's not much of an issue, since more than 1 or 2 slices is rare (currently impossible for x264). Unless chroma planes are separate slices?

Anyway, I'd go for a default of 4. Maximize compatibility and minimize inconvenience. I'd vote that --nalu 2 throw a warning and simply restart with 4 instead of flat erroring out, if the message is already going to be there. It'd be good for those of us die-hards who make streaming video and want to cut every byte of overhead from our 40kbps streams.

Perhaps this could be integrated with the "always use simpleblock" option. Along with no default header values. Sort of an all-inclusive blood-of-turnip option.

Can it fix the nalu size of premuxed stuff coming from mp4/mkv/avi as well?

(It's still a little too happy to read wmvs as AVC ES. But that's my fault for trying to add one.)

Minor bug report: An extra space between --engage no_default_header_values and --engage native_mpeg4 caused mkvmerge to fail.

bob0r

18th January 2007, 10:36

I deleted that source file, i am working on the.recruit.ts 16gb from BBC-HD now, i am trying to cut a none working sample from that.

On my own (clean) captures h264tsto works .ts to .mkv, on this weird cut into 4 pieces .ts it does not, so i hope this will do, else you just need to copy and join the sample as many times till mkvmerge fails :)

I am converting all my .ts files to .mkv, some way or another... i cant stand skipping a .ts and wait 30 seconds for it to continue :O)

Ofcourse i will do this 1x, mirror all files, and never wait again!

Edit:
I am uploading test.h264 842 MB (883,053,919 bytes) to your ftp, this one does this.....
Arg while i am typing this, it did manage to create the file.

So it seems if the file is too big, there is a memory leak or something, you as programmer should be able to make a 4+GB file out of my 50mb sample, just copy copy copy and join them all.
Can't do much more here....

You may delete test.h264

Mosu

18th January 2007, 11:22

For x264 and Ateme, it's not much of an issue, since more than 1 or 2 slices is rare (currently impossible for x264). Unless chroma planes are separate slices?

It's not a matter of the number of slices, because each slice is prefixed with the NALU size. Maybe I'm using the term "slice" in the wrong way here, I'm not sure. Maybe I mean that there can be several NALUs for each frame, and each NALU has its own size.

Anyway, I'd go for a default of 4. Maximize compatibility and minimize inconvenience. I'd vote that --nalu 2 throw a warning and simply restart with 4 instead of flat erroring out, if the message is already going to be there.

"Simply restarting" is not as simple :/ Quite a lot of work.

Perhaps this could be integrated with the "always use simpleblock" option. Along with no default header values. Sort of an all-inclusive blood-of-turnip option.

Nah. I'll leave all options separate and not merge them into one "do it this way or the other way" option. But the options will get their own dialog soon.

Can it fix the nalu size of premuxed stuff coming from mp4/mkv/avi as well?

Not yet, but that's easy to implement. I hadn't thought of it before...

(It's still a little too happy to read wmvs as AVC ES. But that's my fault for trying to add one.)

No WMV support in the near future. Sorry.

Minor bug report: An extra space between --engage no_default_header_values and --engage native_mpeg4 caused mkvmerge to fail.

Huh? Extra spaces should be ignored by mkvmerge... OK, maybe mmg is interpreting this as an extra option. Will have to look.

foxyshadis

18th January 2007, 11:35

It's not a matter of the number of slices, because each slice is prefixed with the NALU size. Maybe I'm using the term "slice" in the wrong way here, I'm not sure. Maybe I mean that there can be several NALUs for each frame, and each NALU has its own size.
I just meant the added overhead for single- or two-nalu frames will be pretty negligible, sorry, compared to your example.

"Simply restarting" is not as simple :/ Quite a lot of work.
I was thinking, mkvmerge itself would error out with a specific error code, and mmg would go back and feed it the new command line. It seems to be simpler than restarting internally in mkvmerge. If that's what you're thinking, apologies.

Mosu

18th January 2007, 14:07

I was thinking, mkvmerge itself would error out with a specific error code, and mmg would go back and feed it the new command line. It seems to be simpler than restarting internally in mkvmerge. If that's what you're thinking, apologies.

That's possible, of course, but there are a lot of folks who use mkvmerge without mmg, and for those this would not be a proper solution.

madshi

18th January 2007, 21:29

@Mosu, I feel a bit bad to ask you this, as you've done so much already and you're already looking into TS import (which would be lovely), but have you thought about adding EVOB import yet? I'm asking because I've read in another thread that it's very similar to MPG, just with some additions or something like that. If you don't want to do it, just say no, that's ok. But I thought it wouldn't harm to ask... :)

FWIW, I just dropped a little EVOB with a MPEG2 video stream into mmg and mkvmerge successfully imported the MPEG2 stream into a mkv!!! It just didn't find the audio part. So it seems that mkvmerge already understands EVOB quite a bit, just not completely.

Here's a thread about EVOB demuxing:

http://forum.doom9.org/showthread.php?t=120652&page=5

At page 3 drmpeg offers a little EVOB demuxer. Maybe he'd be willing to spill the beans about what (if any) changes EVOB has to MPG/VOB?

P.S: Actually his EVOB demuxer comes with full source code and it looks VERY simple! :)

Mosu

18th January 2007, 21:36

EVOB is definitely not on my top-priority-list for at least the next two months :)

madshi

18th January 2007, 21:57

Ok, thanks anyway!

You may ignore this:
(FWIW, my current impression is that EVOB is nothing but MPG. It seems to me that mkvmerge already fully supports EVOB - it just doesn't understand some of the stream IDs. I've just tried the TMPGEnc Demuxer Tool and it shows all streams just fine and can extract them successfully. It seems that 0xBF is Dolby Digital Plus and 0xFD is VC-1.)

Isochroma

18th January 2007, 22:07

Sorry to report, but mkvmerge doesn't 'fully' understand EVOBs... mine causes mkvmerge to hang with 100% CPU usage.

LeMoi

27th January 2007, 23:10

Error: 'H:\file.mkv' track 1: This AVC/h.264 contains frames that are too big for the current maximum NALU size. You have to re-run mkvmerge and set the maximum NALU size to 3 for this track (command line parameter '--nalu-size-length 1:3').
Nalu case is greyed in MMG :s
EDIT : never mind, i was able to add it "extra options" for the track. Anyway it's not normal that this case is greyed :p

Mosu

28th January 2007, 00:14

FWIW, my current impression is that EVOB is nothing but MPG.

Following the discussions and patches on the mplayer mailing lists I think that EVOB is basically VOB with a couple of small but important differences.

Sorry to report, but mkvmerge doesn't 'fully' understand EVOBs... mine causes mkvmerge to hang with 100% CPU usage.

I'm not suprised at all :)

Nalu case is greyed in MMG :s

Ah yes. I think it's only active for AVC ES files at the moment, neither for AVC-in-AVI nor for AVC-in-VfW-mode-in-Matroska. I'll fix that soon.

Isochroma

29th January 2007, 20:28

Just to let you know, I'm having the same problem as LeMoi - I have an MKV with VFW track fourcc "H264". I cannot be remuxed with 2.0.0 beause the NALU setting box is grayed out.

When I copy the cmdline and paste into cmdbox with the recommended nalu string added, it doesn't work, complaining about a track missing.

Mosu

30th January 2007, 08:56

Also, I've encountered two more .mp4 files that after muxing won't play (stuck on frame 0, won't seek).

Upload, please :)

Yong

30th January 2007, 11:43

Mosu, i have a good thing for you:p

mkvtoolnix tell me this sample is h264 es...
its actually is png/qdm2 mov.
http://www.shynola.com/movies/j_s/moveyourfeet.mov

more info about the mov read this thread:)
http://forum.doom9.org/showthread.php?p=926535#post926535

Mosu

30th January 2007, 21:05

Mosu, i have a good thing for you:p

mkvtoolnix tell me this sample is h264 es...
its actually is png/qdm2 mov.
http://www.shynola.com/movies/j_s/moveyourfeet.mov

Hmm. Ok, I've fixed the file type detection issue, so the file is recognized as QT/MP4 now. But PNG video tracks are not supported, and I won't add support for them now. So you'd only be able to mux the audio track.

Yong

30th January 2007, 22:53

Hmm. Ok, I've fixed the file type detection issue, so the file is recognized as QT/MP4 now. But PNG video tracks are not supported, and I won't add support for them now. So you'd only be able to mux the audio track.

Great, i didnt expect you to add support for it, just a bug report;)
and thx for the hard work.

Isochroma

1st February 2007, 04:23

I have an AVI file which has 119.880 fps drop-frame H264 inside. Using previous versions of MKVMerge, I could mux into MKV using the VFW override and it would work great.

The current version can't mux the source because the NALU needs to be set larger.

But I'm wondering, how will MKVMerge deal with the 119.880 drop frames? Because the old way it was stored, the drop frames were just preserved in the VFW-mode structure, right?

But the new native format for AVC will require that those drop frames be removed, because there is no drop-frames outside of VFW tracks, right?

Personally, I'd prefer if the next version of MKVMerge restored the ability to mux H264 from VFW mode to VFW-mode tracks. The reason is until the native support is debugged, there is no way to mux certain VFW mode tracks, and it is uncertain what will happen to drop frames. New versions have become less useful by omitting the VFW function, such that they cannot be used on a significant fraction of files of this type.

This kind of gap is bound to happen in such rapid developement, of course. Rest assured I have faith that soon, such cases will be handled properly. Blame for these cases ultimately reverts to those who used VFW mode for H264 tracks. MP4 and native AVC mode in MKV are a kind of salvation for this sin; and as priests, MKVMerge and MP4Box can provide redemption, perhaps even salvation. Thus it is easy to understand why the AVC-in-VFW option was removed: to prevent the passing on into new files of corruption, a corrupt practice or way of doing something.

I also tried the latest MP4Box GUI YAMB; it reported an unspecified error and failed. So I guess right now MKVMerge is the last hope for this type of file...

Mosu

1st February 2007, 08:58

But I'm wondering, how will MKVMerge deal with the 119.880 drop frames? Because the old way it was stored, the drop frames were just preserved in the VFW-mode structure, right?

Wrong. mkvmerge has always removed zero-sized entries.

But the new native format for AVC will require that those drop frames be removed, because there is no drop-frames outside of VFW tracks, right?

They should be removed, yes.

Personally, I'd prefer if the next version of MKVMerge restored the ability to mux H264 from VFW mode to VFW-mode tracks.

This will definitely not happen. The vfw-mode storage has always been the wrong thing to do, and I only left it in because mkvmerge couldn't handle such files any other way at that point.

You can try this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.0.0-build20070201-1.rar

It defaults to a NALU size of 4 and mmg allows the selection of the NALU size if the AVC track comes from an AVI or VFW-mode Matroska file.

BTW: If this build does not work right with your file then I'd be very happy if you uploaded it to my FTP server. I don't have a single 119.880 FPS AVI file, especially not with h264 inside.

Milvus

1st February 2007, 12:11

But I'm wondering, how will MKVMerge deal with the 119.880 drop frames? Because the old way it was stored, the drop frames were just preserved in the VFW-mode structure, right?

These 119.88fps pseudo-VFR AVI files are quite an abomination, and storing them as is in MKV is definitely a wrong idea. It can lead to jerky playback on some computer.

The right thing to do was to use avi_tc_package (http://web.missouri.edu/~kes25c/#c3) to convert the original AVI file to a CFR AVI without dropframes and a timecode file. MKVmerge can then use them to produce a true MKV VFR with native AVC.

But now that MKVmerge can handle them correctly, I suppose there's no further need to complicate our life. We have true MKV VFR with native AVC directly !

dragonle87

1st February 2007, 16:09

Hello, forgive me if this is the wrong thread to post this but I would like to request two small features be implemented:

1) Can you make it so that users can select which "command line options" to always be enabled by default, instead of having to manually select it from the "Muxing" menu? It's because I always use "--engage native_mpeg4" for every file that I muxed to be clean of avi compatibility hacks. I got this idea when I saw you have the checkbox option "Always use simple blocks" under the "Settings" tab.

2) Another thing i regularly do when muxing files to mkv is naming it in the "file/segment title" textbox under the "Global" tab. The only thing missing is an additional separate "creator/author" textbox and I was wondering if you could add that in your next version. Having a "title" and "author" textboxes is really useful for providing very basic file information. I find this simple, fast, and convenient rather than going through the trouble of creating tags, which I think should be reserved for those users who want to provide more detailed file information.

Most of all, keep up the good work, your program just rocks. As an avid mkv user, I really enjoy using it...very easy and straightforward at creating mkv files.

LeMoi

1st February 2007, 16:40

2) Another thing i regularly do when muxing files to mkv is naming it in the "file/segment title" textbox under the "Global" tab. The only thing missing is an additional separate "creator/author" textbox and I was wondering if you could add that in your next version. Having a "title" and "author" textboxes is really useful for providing very basic file information. I find this simple, fast, and convenient rather than going through the trouble of creating tags, which I think should be reserved for those users who want to provide more detailed file information.
+1 :)

Mosu

1st February 2007, 17:17

1) Can you make it so that users can select which "command line options" to always be enabled by default, instead of having to manually select it from the "Muxing" menu? It's because I always use "--engage native_mpeg4" for every file that I muxed to be clean of avi compatibility hacks. I got this idea when I saw you have the checkbox option "Always use simple blocks" under the "Settings" tab.

I can certainly do this. I've been planning to move the "settings" tab to its own dialog because it's growing with each release. In such a dialog I'll also add an input box in which the user can set default options which will be added to the command line.

2) Another thing i regularly do when muxing files to mkv is naming it in the "file/segment title" textbox under the "Global" tab. The only thing missing is an additional separate "creator/author" textbox and I was wondering if you could add that in your next version. Having a "title" and "author" textboxes is really useful for providing very basic file information. I find this simple, fast, and convenient rather than going through the trouble of creating tags, which I think should be reserved for those users who want to provide more detailed file information.

I can do that as well. This information would still have to be put into the tags because there's no other place in a Matroska file for this kind of information. The segment title is different; there's an element for this in the segment headers. But it would at least be a convenient way to add some basic information. Maybe I'll offer a complete tab "basic tags" or something like this... I'll have to think about it.

Note that neither change will happen soon. I'm also in the process of rewriting mmg using the Qt toolkit, and this takes precedence over huge changes to the current GUI.

Most of all, keep up the good work, your program just rocks. As an avid mkv user, I really enjoy using it...very easy and straightforward at creating mkv files.[/QUOTE]

Isochroma

1st February 2007, 19:11

@millvus: I already tried the avc_tc package. It was time-consuming, and no matter what I did the end result was a file that didn't play right - the audio was always going out of sync.

@Mosu: will give it a try!

Okraml

1st February 2007, 21:01

Will there be VC1 support annytime soon?
Then mkvtoolnix would be the first application for muxing vc1 (demuxed from evob) to a new container (maybe with another-language audio stream).

:-) Okraml

LeMoi

1st February 2007, 21:15

I was muxing a file with mmg and it fails with code 2 errors, without displaying the error message. I had to use command line to see it :mkvmerge v2.0.0 ('After The Rain Has Fallen') built on Jan 17 2007 10:43:41

Error: Error: Simple chapter parser: 'CHAPTER01NAME=Chapitre n
Shouldn't the GUI display it ?

Mosu

1st February 2007, 21:19

Will there be VC1 support annytime soon?
Then mkvtoolnix would be the first application for muxing vc1 (demuxed from evob) to a new container (maybe with another-language audio stream).

:-) Okraml

Hmm I don't have any information about VC1, nor sample files, nor is there a CodecId for it... So... Probably not.

Mosu

1st February 2007, 21:22

I was muxing a file with mmg and it fails with code 2 errors, without displaying the error message. I had to use command line to see it :
Shouldn't the GUI display it ?

Hmm it should, yes... I'll investigate.

Okraml

1st February 2007, 21:27

Hmm I don't have any information about VC1, nor sample files, nor is there a CodecId for it... So... Probably not.

Would it help, if i would upload sample files?

A working ID could be WVC1. At least thats what mkvtoolnix recognized in this case (http://forum.doom9.org/showthread.php?p=946196#post946196).
(I could even upload one of the files mentioned in the post)

:-) Okraml

Mosu

1st February 2007, 21:36

Samples files always help. I'll also need a way to play back the files. Meaning a decoder and some demuxer that can handle evobs. I think mplayer cannot really do that yet, even with current SVN...

Mosu

1st February 2007, 21:39

Oh, AND I need files with LOWER resolutions. My computer cannot handle HDTV resolutions.

Okraml

1st February 2007, 21:42

Oh, AND I need files with LOWER resolutions. My computer cannot handle HDTV resolutions.

You don't need HDTV resolutions to be able to just play the files. I could play 1080i on a 17inch display with a resolution of 1280x1024.

:-) Okraml

Mosu

1st February 2007, 21:45

Well, what I meant is that my PC can only decode 1900x1200 resolutions with 3 or 4 frames per second :) Definitely not enough to see if the muxed file is OK or not.

Okraml

1st February 2007, 21:50

Well, what I meant is that my PC can only decode 1900x1200 resolutions with 3 or 4 frames per second :) Definitely not enough to see if the muxed file is OK or not.

Unfortunately i got no vc1 file with lower resolution. I could test for you, if you can get mkvtoolnix to mux a whole file (for now it doesn't recognize the file and with haali matroska muxer i can't get a whole file muxed neither).

:-) Okraml

Isochroma

1st February 2007, 22:05

Eragon4ever

1st February 2007, 22:42

I just experimented a bit with "--engage native_mpeg4".
Some of my files get out of sync after muxing them with "--engage native_mpeg4" enabled and at least one seams to drop some frames. When remuxing the mkvs both show a warning like this:

pr_generic.cpp/generic_packetizer_c::add_packet(): timecode < last_timecode (00:00:00.083 < 00:00:00.167) for 1 of 'N:\Bearbeiten\Death Note\[subs4u]_DeathNote_01HQ_(Xvid,ger.sub)[F53CD5E2].mkv'. This should not have happened.

No problem with vfw.

I'll upload a sample if needed.

Mosu

1st February 2007, 22:50

Unfortunately i got no vc1 file with lower resolution. I could test for you, if you can get mkvtoolnix to mux a whole file (for now it doesn't recognize the file and with haali matroska muxer i can't get a whole file muxed neither).

:-) Okraml

I've downloaded a couple of samples from mplayer's server. Maybe I can start with those.

Note: Don't hold your breath. This will take lots of time.

Mosu

1st February 2007, 22:52

The new build works great; one minor item I noticed, however, is that the muxed file shows in its properties (MatroskaProp) 119.880127 fps.

I have done some VFR MP4 to MKV muxing before, and in those cases the fps shows as something like 27.2 or similar, so I was wondering why it still shows 119.880127?

mkvmerge just uses the AVI's FPS field. It doesn't re-calculate or guess the actual number of frames that aren't dropped. For MP4 files it's similar... Only MP4 files don't really have a FPS field; they have something similar to Matroska's default duration.

Mosu

1st February 2007, 22:57

Eragon4ever

2nd February 2007, 00:13

Yeah, a sample file would be nice. Maybe it's time to fix native MPEG4 mode for good.
Sample is up (DeathNote_01HQ).

And an other thing: Once you have muxed an H.264 AVI with NALU 3 you have to demux it first to set the NALU to 4 in case the decoder does not work with 3 (maybe command line works to but not with GUI). It would be nice to be able to set the NALU for mkv (and mp4), too.

Isochroma

2nd February 2007, 00:35

I've noticed that the same mpeg-4 asp .avi (dx50, xvid, etc.) muxed in mkv with native and vfw modes, uses more cpu on playback in native mode than vfw mode.

Mosu

2nd February 2007, 08:18

Sample is up (DeathNote_01HQ).

Thanks.

And an other thing: Once you have muxed an H.264 AVI with NALU 3 you have to demux it first to set the NALU to 4 in case the decoder does not work with 3 (maybe command line works to but not with GUI). It would be nice to be able to set the NALU for mkv (and mp4), too.

Hmmmmmmmmmmm I see your point. Might not be that hard to implement.

Mosu

2nd February 2007, 08:20

I've noticed that the same mpeg-4 asp .avi (dx50, xvid, etc.) muxed in mkv with native and vfw modes, uses more cpu on playback in native mode than vfw mode.

How much more and on what kind of a CPU? (This might be due to the timecodes having to be reordered and frames to be cached, I'm not sure... I don't know how demuxers handle those out-of-order timecodes.)

Isochroma

2nd February 2007, 19:02

It's probably the splitter's issue, so no need to worry. Athlon XP and some old hi-def material that I encoded (1368x768), before I discovered WMV2.

madshi

4th February 2007, 21:14

@Mosu, just noticed that in the latest mkvtoolnix software it's possible to explicitly deny the "default" state of a track. That's VERY nice. Why? Because I want to have subtitles in my movies, but I don't want them to be activated by default. Up until now MPC always showed subtitles by default. I thought it was just a bad decision by MPC. But now actually I understand that mkvtoolnix always marked one subtitle track as default and MPC just obeyed. Now when I mux subtitles to my movies and say "no" for all subtitles, MPC doesn't activate any subtitles by default, anymore. Great!!

There's one bug, though: When I have a MKV movie which has already subtitles in it and if one of the subtitle tracks is already marked as default, I cannot undo the "default" marking, anymore. Even explicitly specifying "--default-track 4:no" doesn't remove the "default" marking. Would you mind looking into this, when you have some time? It isn't urgent, but having this fixed would be nice.

Mosu

4th February 2007, 21:46

This feature was neccessary because pretty much all player/splitter developpers were mis-intepreting the Matroska specs. Anyway... I'll look at the bug.

Palikrovol

5th February 2007, 01:10

Mosu

5th February 2007, 09:12

What's the difference between 'default' and 'yes' in the "Default track flag"?

"Yes" forces this track to be the default track for its kind (audio, video, subtitles). "Default" lets mkvmerge make this decision. If all track of a kind are set to "Default" then mkvmerge will a) honor the source container's "Default Track Flag" (only relevant if you're copying from Matroska files at the moment) and b) mark the first track found of each kind as being the default track if no flag was found in the source containers.

madshi

5th February 2007, 09:33

@Mosu: A somewhat strange question. Would it be difficult/time consuming for you to add a feature to mkvmerge, which would allow to:

(1) Extract a specific key frame (eventually with following non-key frames) to a new mkv. And:
(2) Remove a specific range of key frames from the mkv?

If that would be very easy for you to realize that would be a nice feature, cause it would allow to remove advertising out of H.264 videos - which no software can do today. Eventually somebody could even write a little GUI program based on such mkvmerge features which allows cutting of mkv movies.

But if it's not as simple as just doing "splitting" + "joining" (which you already can do) with just some other parameters, then please don't spend time on this. There are probably more important things to spend time on.

Mosu

5th February 2007, 10:01

Yeah, it's not as easy as it may sound ;) I've been asked to implement such a "use only these frames" feature from time to time, but it would require a lot of time to implement. So not in the near future.

madshi

5th February 2007, 10:19

Ok, thanks... :)

Jaxel

7th February 2007, 05:10

okay... I am having one other issue... I have noticed, any period with "no-sound" is recorded by mkvmerge as non-MP3 data. For instance, at the beginning of my video, I may have a few frames of silence... this is what mkvmerge will tell me...

mkvmerge v2.0.0 ('After The Rain Has Fallen') built on Feb 1 2007 08:56:12
'Z:\nh3.demo.Ougi.Part1.avi': Using the AVI demultiplexer. Opening file. This may take some time depending on the file's size.
'Z:\nh3.demo.Ougi.Part1.avi' track 0: Using the MPEG-4 part 10 ES video output module.
'Z:\nh3.demo.Ougi.Part1.avi' track 1: Using the MPEG audio output module.
The file 'Z:\nh3.demo.Ougi.Part1.mkv' has been opened for writing.
The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 315 bytes of non-MP3 data at the beginning.
This corresponds to a delay of 19ms. This delay will be used instead of the garbage data.
The cue entries (the index) are being written...
Muxing took 8 seconds.

Now this isnt a problem, it automatically writes in a 19ms delay to even out the areas of non-MP3 data (which is nothing more than "no-sound"). The problem I have is during the video in between scenes, there are also points of "no-sound". I didn't put these points in, when I was recorded the videos off my PS2, during these times, there was just no-sound playing. So during the encode I get the following:

Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 358 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 252 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 168 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 178 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 101 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 199 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 91 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 344 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 92 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 394 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 159 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 264 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 48 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 147 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 332 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 344 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 368 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 158 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 112 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 347 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 42 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 186 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 80 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 323 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 228 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 253 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 42 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 252 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 416 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 217 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 58 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 364 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 178 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 319 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 51 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 305 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 228 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 203 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 41 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 344 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 134 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 379 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 30 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 42 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 277 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 52 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 319 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 279 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 37 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 299 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 137 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 67 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 403 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 66 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 198 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 72 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 60 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 121 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 147 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 317 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 113 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 146 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.
Warning: The MPEG audio track 1 from 'Z:\nh3.demo.Ougi.Part1.avi' contained 256 bytes of non-MP3
data which were skipped. The audio/video synchronization may have been lost.

Each part is not a lot of data... 100-300 bytes here and there isnt a problem... But when this happens 50 times in a single video, by the end the sound is out of sync. Is there any way to get mkvmerge to ignore these errors and keep these bytes intact? Or possibly replace these bytes with delays equivalent to the timing?

Here is the link to the AVI-VFW video I am trying to mux in mkvmerge...
http://www.crookedjester.com/downloads/nh3.demo.Ougi.Part1.avi

Mosu

7th February 2007, 09:22

okay... I am having one other issue... I have noticed, any period with "no-sound" is recorded by mkvmerge as non-MP3 data.

Which is exactly what it is. Your "no sound" is actually filled with bytes, but they're just random or whatever you may call it. Such random stuff is not allowed in Matroska, so mkvmerge skips them. Until now I only encountered such stuff at the beginning of a file but never in the middle, especially not so many occurences.

Each part is not a lot of data... 100-300 bytes here and there isnt a problem... But when this happens 50 times in a single video, by the end the sound is out of sync. Is there any way to get mkvmerge to ignore these errors and keep these bytes intact? Or possibly replace these bytes with delays equivalent to the timing?

Replacing them with silent MP3 frames is possible but risky. Each MP3 frame contains 1152 samples, so depending on the sample rate each MP3 frame is 26ms (44100 Hz) or 24ms (48000 Hz) long. Meaning that depending on the length of garbage found sound could still go out of sync.

What I could do is calculate the gap's length and add that to the timecodes from that point on. I don't know how players will react, but they SHOULD do the right thing. Don't count on me getting this ready in the next few days, though.

Here is the link to the AVI-VFW video I am trying to mux in mkvmerge...
http://www.crookedjester.com/downloads/nh3.demo.Ougi.Part1.avi

Downloading, thanks for the sample.

LeMoi

7th February 2007, 11:37

http://www.bunkus.org/videotools/mkvtoolnix/avc-status.html seems to be outdated :)

Jaxel

7th February 2007, 13:48

Ah... well I figure, in between each scene in the video is a menu system on the PS2 game... so I cut those menu system scenes out of the final video... I guess when I was cutting the video, I cut in the middle of samples, so the garbage data are split samples in between scenes.

tjf

9th February 2007, 12:24

For long time I have problem with asigning language to a subtitle. The last version where it worked properly was 1.7.

I have x264 video, with AC3 audio, chapters and two srt subtitle streams. English and Czech. Here is the screenshot and command line output for v 1.7:

http://www.volny.cz/tfojta/mkv/170.png

"mkvmerge" -o "E:\Movies\Ice Age\Ice Age1.mkv" --language 1:eng --track-name "1:Ice Age" --default-track 1 --aspect-ratio 1:1.911 -d 1 -A -S "E:\Movies\Ice Age\Ice Age.mkv" --language 0:eng -a 0 -D -S "E:\Movies\Ice Age\Ice Age T02 3_2ch 448Kbps DELAY 0ms.ac3" --language 0:eng -s 0 -D -A "E:\Movies\Ice Age\English.srt" --language 0:cze -s 0 -D -A "E:\Movies\Ice Age\Czech.srt" --track-order 0:1,1:0,2:0,3:0 --chapters "E:\Movies\Ice Age\chapters.txt"

And this is from 2.0. Notice the missing language properties in the command line.

http://www.volny.cz/tfojta/mkv/200.png

"mkvmerge" -o "E:\Movies\Ice Age\Ice Age.mkv" --language 1:eng --track-name "1:Ice Age" --default-track 1 --aspect-ratio 1:1.911 -d 1 -A -S "E:\Movies\Ice Age\Ice Age.mkv" --sync 0:0 -a 0 -D -S "E:\Movies\Ice Age\Ice Age T02 3_2ch 448Kbps DELAY 0ms.ac3" --language 0:eng -s 0 -D -A "E:\Movies\Ice Age\English.srt" -s 0 -D -A "E:\Movies\Ice Age\Czech.srt" --track-order 0:1,1:0,2:0,3:0 --chapters "E:\Movies\Ice Age\chapters.txt"

Is it a bug or am I doing something wrong?

Tomas

Mosu

9th February 2007, 15:11

For long time I have problem with asigning language to a subtitle. The last version where it worked properly was 1.7.

...

I cannot reproduce this on Windows. Please tell me exactly what you've done. Meaning each and every mouse click, track change, whatever.

tjf

9th February 2007, 19:46

I cannot reproduce this on Windows. Please tell me exactly what you've done. Meaning each and every mouse click, track change, whatever.

Input files:
Add -> select file "Ice age.mkv"
Add -> select file "English.srt"
Add -> select file "Czech.srt"

Tracks:
highlight SRT (ID0, type: subtitles) from English.srt ...

General track options
Language: select English

Tracks:
highlight SRT (ID0, type: subtitles) from Czech.srt ...
Language: select Czech

I see no change in Command line (the Czech parameter is not added)

"mkvmerge" -o "E:\Movies\Ice Age\Ice Age.mkv" --language 1:eng --default-track 1 --display-dimensions 1:45x34 -d 1 -A -S "E:\Movies\Ice Age\Ice Age.mkv" --language 0:eng -s 0 -D -A "E:\Movies\Ice Age\English.srt" -s 0 -D -A "E:\Movies\Ice Age\Czech.srt" --track-order 0:1,1:0,2:0

If I switch away in tracks and return to the Czech.srt, the Language in General track options says 'und (Undetermined)'

Tomas

Mosu

9th February 2007, 19:55

Thanks for the info. Last question: Which mkvmerge build is your 2.0.0 build? Unicode / non-Unicode? Exact version information (you can find this under "Help" -> "About" -> "...built on DATE")?

tjf

10th February 2007, 00:04

Thanks for the info. Last question: Which mkvmerge build is your 2.0.0 build? Unicode / non-Unicode? Exact version information (you can find this under "Help" -> "About" -> "...built on DATE")?

unicode, Jan 13 2007 20:06:07

tomos

10th February 2007, 05:06

Hi,

I'm wondering if there is any way to get mkvmerge to see DD+ audio tracks correctly? At the moment, it sees them as video tracks for some reason.

when i drop the track in i get:

Message
---------------------------
You're adding an AVC/h.264 elementary stream to the output file. mkvmerge cannot determine the number of frames per second for such files itself. Therefore you have to set this parameter yourself on the 'format specific options' page.

If you don't do this then mkvmerge will assume 25 fps.

This message will only be shown once unless you have enabled mmg's warnings on its 'settings' page.

once i OK this, mkvmerge sees the files as:

mpeg-4 part 10 ES (ID 0, type: video)

but this is just the plain audio - no video at all. the ddp files plays fine in mpc

i am using v2 btw,
mkvmerge GUI v2.0.0 ('After The Rain Has Fallen')
built on Jan 13 2007 20:25:47

Isochroma

10th February 2007, 05:28

Same here...

Mosu

10th February 2007, 13:03

Hi,

I'm wondering if there is any way to get mkvmerge to see DD+ audio tracks correctly? At the moment, it sees them as video tracks for some reason.

What is DD+? Modified AC3 from HD DVDs or something like this?

tomos

10th February 2007, 13:18

as far as i know, yes. - well, demuxed from hd-dvds

madshi

10th February 2007, 13:46

What is DD+? Modified AC3 from HD DVDs or something like this?
http://en.wikipedia.org/wiki/Dolby_Digital_Plus

madshi

10th February 2007, 23:47

@Mosu, just got a bunch of lines like this:

Warning: pr_generic.cpp/generic_packetizer_c::add_packet(): timecode < last_timecode (00:00:00.934 < 00:00:00.984) for 1 of 'D:\Honey.mkv'. This should not have happened. Please contact the author [...] with this error/warning message, a description of what you were trying to do, the command line used and which operating system you are using. Thank you.
Here's the command line:

"mkvmerge" -o "D:\Honey new.mkv" --language 1:eng --default-track 1:yes --display-dimensions 1:1920x1080 -d 1 -A -S "D:\Honey.mkv" --track-order 0:1
Originally I wanted to replace the one and only english AC3 audio track in Honey.mkv with a new one. But I can reproduce the problem just with taking the Honey.mkv and muxing the video only into another mkv. The video is MPEG2. The mkv was created by converting a TS file through Haali's Media Splitter + Matroska Muxer.

Eragon4ever

11th February 2007, 00:52

Looks like the message I get when I try to remux a mkv created with "--engage native_mpeg4" enabled. (see page 5)

har-vas

18th February 2007, 05:59

Hello all. I would like to ask for/propose some features regarding mkvmerge.
1. I like very much the (very flexible) Chapter Editor and I am using it, but I think that it would be great if it had the possibility to directly import chapters from an IFO file (like it does from .mkv files). Now I am using the well-known (and abandoned?) ChapterXtractor for that purpose and then import the .txt file in Chapter Editor. So is it possible to directly import chapters from a DVD in Chapter Editor? Is this feature in author's plans for the future?
2. What about a Tag Editor? I imagine a new tab in mmg with a list of all the official tag names (maybe in groups), so that you have just to select a tag, enter the value for it, then select another tag (either as a child of the previous or in the same level with it), enter the value for it etc. Also a syntax check function would be necessary (to verify integrity). Now I have to edit manually a text file to handle my tags...
3. Also I would like to be restored the "allow_avc_in_vfw_mode" hack, but this is something that the author has ruled out. Personally, I am using many mkv files with x264 VfW video streams (created by GordianKnot 0.35), mainly TV captures, which finally I load in VirtualDubMod to throw out ads or to isolate a small part of the video. I was very disappointed when I saw that this feature went away in MKVtoolnix 2.0. I respect the developer's decision (who always knows what is better of course), but as an end-user I would like to receive an explanation. Why an optional program's feature, which someone could freely decide to use, went away? Was it so bad feature, a source of other problems maybe? Or was just a tactical decision to stop even the last support for x264 VfW?
4. Anyway, is there any alternative solution for easy post-editing native x264 streams stored in matroska? Thanks.

bob0r

18th February 2007, 20:21

Arg, still no H.264 MBAFF support? :/

Mosu

18th February 2007, 20:34

What is h.264 MBAFF?

ExarKun634

18th February 2007, 20:56

What is h.264 MBAFF?Man, you just aren't up on your HDTV terms, are you? (Just kidding)

Apparently, it stands for MacroBlock-level Adaptive Frame/Field, and it referes to a method of coding interlaced MPEG4AVC/H264 content.

It's of importance right now, because it is how BBC-HD is broadcasting their MPEG4AVC/H264 content.

Mosu

18th February 2007, 21:07

Man, you just aren't up on your HDTV terms, are you? (Just kidding)

;) I don't have HDTV capable equipment and will not have for quite some time. Therefore I'm not really interested in it, hence I don't know these terms.

Apparently, it stands for MacroBlock-level Adaptive Frame/Field, and it referes to a method of coding interlaced MPEG4AVC/H264 content.

It's of importance right now, because it is how BBC-HD is broadcasting their MPEG4AVC/H264 content.

Sample files? How is storage different from normal h264? How can I recognize what type of stream it is? Can mp4box handle them correctly?

Borbus

18th February 2007, 21:16

You can get a sample of BBC-HD from here: http://www.gigasize.com/get.php/23058/BBC_HD1.ts

It was posted by another doom9 user a while ago.

There are more in this thread: http://forum.doom9.org/showthread.php?t=115667

Mosu

18th February 2007, 21:33

Transport streams are not supported. Only elementary streams. Any way to get the ES from the TS?

madshi

18th February 2007, 21:46

Transport streams are not supported. Only elementary streams. Any way to get the ES from the TS?
Sure. There are several ways. E.g. by using GraphEdit (Elecard Demuxer -> Dump) or by using mplayer with command line commands. Or by using Haali's Media Splitter + Haali's Matroska Muxer + mkvExtract.

bob0r

18th February 2007, 21:51

Yup LOL i gave all those samples.....and you are like what are they? :p

It also seems haali dsmux (and so h264tsto) have problems with BIG files...... i am not a coder so i should not complain, but i am dutch so i will:

Its pathetic big files are still an issue today :/

mkv still SUCKS on MAC..... progress is really crappy....... i wish i never learned about all this HD stuff :D

Ok thanks for the replies!

Mosu

20th February 2007, 15:41

Hello all. I would like to ask for/propose some features regarding mkvmerge.
1. I like very much the (very flexible) Chapter Editor and I am using it, but I think that it would be great if it had the possibility to directly import chapters from an IFO file (like it does from .mkv files). Now I am using the well-known (and abandoned?) ChapterXtractor for that purpose and then import the .txt file in Chapter Editor. So is it possible to directly import chapters from a DVD in Chapter Editor? Is this feature in author's plans for the future?

I'll probably implement this. I already have code which uses libdvdread and retrieves the chapters; it's "just" a matter of integrating into mmg.

2. What about a Tag Editor?

No. Not enough time.

3. Also I would like to be restored the "allow_avc_in_vfw_mode" hack, but this is something that the author has ruled out. Personally, I am using many mkv files with x264 VfW video streams (created by GordianKnot 0.35), mainly TV captures, which finally I load in VirtualDubMod to throw out ads or to isolate a small part of the video. I was very disappointed when I saw that this feature went away in MKVtoolnix 2.0. I respect the developer's decision (who always knows what is better of course), but as an end-user I would like to receive an explanation. Why an optional program's feature, which someone could freely decide to use, went away? Was it so bad feature, a source of other problems maybe? Or was just a tactical decision to stop even the last support for x264 VfW?

I've re-added this feature.

Mosu

20th February 2007, 15:52

http://en.wikipedia.org/wiki/Dolby_Digital_Plus

Thanks. There will be no support for DD+ for the time being because a) I cannot find any specs, b) I don't have any means of playing back such a file (neither hardware nor software).

Mosu

21st February 2007, 14:47

Hey users,

here's mkvtoolnix 2.0.2. A couple of bug fixes, especially in the h.264, some minor new features is about all. If you compile it yourself make sure to get libmatroska 0.8.1 which this release depends upon from http://dl.matroska.org/downloads/libmatroska/

The usual links...
...to the home page:
http://www.bunkus.org/videotools/mkvtoolnix/
...the source code:
http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-2.0.2.tar.bz2
...the Windows Unicode enabled binaries:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-2.0.2-setup.exe

More binaries for Linux and other OS are available from the home page.

Here's the ChangeLog since 2.0.0:

-----------------------------------------------------------
2007-02-21 Moritz Bunkus <moritz@bunkus.org>
* Released v2.0.2.

2007-02-19 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: Reintroduced the "--engage allow_avc_in_vfw_mode" hack.

2007-02-06 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed suppoert for DTS-in-WAV files which are encoded with 14 bits per word.

2007-02-03 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: Added support for DTS files which use only 14 out of every 16 bits and which are not stored inside a WAV file.

2007-01-30 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mmg: Changed the default for the "NALU size length" to "4" and added a warning if "3" is used.
* mkvmerge: bug fix: File type detection for Qt/MP4 files which start with a "wide" atom has been fixed.
* mmg: bug fix: The "NALU size length" drop down box is now also enabled for h.264 tracks read from AVIs and for h.264 tracks stored in "VfW compatibility mode" in Matroska files.

2007-01-28 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mmg: new feature: Extended the option "--default-track" so that it can be forced to "off" allowing the user to create a file for which no track has its "default" flag set. Fix for bug #224.

2007-01-17 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed the wrong "default duration" if the user used "--default-duration ...23.976fps".

2007-01-16 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The AVC/h.264 ES reader was losing frames if the file size was an exact multiple of 1048576 bytes.
* mkvmerge: bug fix: The AVC/h.264 ES packetizer produced invalid CodecPrivate data if the AVCC did not contain the aspect ratio information. Fix for Bugzilla bug #225.
* mkvmerge: bug fix: The Matroska reader passes the correct track number down to the AVC/h.264 ES packetizer in the case of "AVC in Matroska stored in VfW mode".
* mkvmerge: bug fix: Fixed a crash (segmentation fault) in the AVC/h.264 ES handling code.

2007-01-15 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mkvextract, mkvinfo: new feature: Added support for using CodecState for signaling changes to CodecPrivate. It is used for MPEG-1/-2 video if it is turned on with "--engage use_codec_state".
-----------------------------------------------------------

Have fun.

Regards,
Mosu

madshi

21st February 2007, 15:14

Thanks!!

bob0r

21st February 2007, 16:50

1: If you have muxed H.264 previously with nal 3, you open .mkv the nal box is greyed.... do i need to demux/remux to get it fixed or.... ?

2: H.264 MBAFF still not working right?
I get this:
Error: 'I64d' is not a valid file ID in '--track-order 0:I64d,1:I64d'.

cli: "mkvmerge" -o "G:\cap\pride.mkv" --default-duration 0:25fps -d 0 -A -S I:\cap\pride.h264 --sync 0:-698 -a 0 -D -S I:\cap\pride.ac3 --track-order 0:I64d,1:I64d

3:
Weird visual bugs also:
http://x264.nl/mkv2.0.2.visual.bugs.gif

Yong

21st February 2007, 17:44

i dont have the visual bug,
http://img143.imageshack.us/img143/8177/clipboard01lt5.gif
im using vista transformation pack 6.0 in XP SP2. ;)
Try change to other visual style and see if the problem still persist.

Eragon4ever

21st February 2007, 19:22

1: If you have muxed H.264 previously with nal 3, you open .mkv the nal box is greyed.... do i need to demux/remux to get it fixed or.... ?
See my post and his reply.
http://forum.doom9.org/showthread.php?p=947768#post947800

Mosu

21st February 2007, 23:24

mkvmerge does not support re-adjusting the NALU size length of natively muxed h.264 tracks yet. I'm planning to implement that, though I cannot say when I'll get this done.

tomos

21st February 2007, 23:34

Thanks. There will be no support for DD+ for the time being because a) I cannot find any specs, b) I don't have any means of playing back such a file (neither hardware nor software).

:( thanks for looking tho.

Mosu

22nd February 2007, 00:15

2: H.264 MBAFF still not working right?
I get this:
Error: 'I64d' is not a valid file ID in '--track-order 0:I64d,1:I64d'.

F***! This has nothing to do with h.264 but with the new wxWidgets version I'm compiling against... How I hate this! Get rid of one bug and get a random new one...

Sorry guys, please download this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-2.0.2-1-setup.exe
It's linked against the older wxWidgets version again.

3:
Weird visual bugs also:

Never seen this myself, cannot do anything about it. If the older wxWidgets doesn't fix it for you then it'll stay that way.

Isochroma

22nd February 2007, 00:24

Ahh Mosu, I have another delicious file for you!

AVC with OGG in MP4 (132K) (http://www.isochroma.com/Testfiles/Misc/doom9/%5bC1%5dNodame_Cantabile_-_06%5bX264%5d%5bOGG%5d%5bHD%5d%5b479E15D8%5d_001.mp4)

The video remuxes fine with latest MKVMerge, but the audio gives this error and is omitted from the MKV:

Warning: Quicktime/MP4 reader: The audio track 2 is using an unsupported 'object type id' of 221 in the 'esds' atom. Skipping this track.

Why someone would put OGG into MP4 I cannot guess, especially when you've worked so hard to make MKVToolnix the best tool for muxing.

Mosu

22nd February 2007, 08:12

Yeah, mkvmerge does not support Vorbis-in-MP4 yet. But thanks for the sample; that's always the first thing I need :)

madshi

22nd February 2007, 10:36

@Mosu, noticed some weird sound in the beginning of some of my MKV movies. After some thinking about it, what does mkvmerge do if I tell it to delay the audio tracks? Does it loop the beginning of the audio track? Or does it add silence? I guess you're looping the sound? That sounds really weird to me. If possible, I'd prefer if you added silence instead, just like delaycut does. Thanks!

Mosu

22nd February 2007, 14:19

mkvmerge should add silence, but it doesn't support this for all audio formats (only for AC3, MP3, Vorbis if I'm not mistaken). At the moment it creates weird sound for AC3 because it does the wrong thing.

bob0r

22nd February 2007, 14:24

F***! This has nothing to do with h.264 but with the new wxWidgets version I'm compiling against... How I hate this! Get rid of one bug and get a random new one...

Sorry guys, please download this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-2.0.2-1-setup.exe
It's linked against the older wxWidgets version again.

Never seen this myself, cannot do anything about it. If the older wxWidgets doesn't fix it for you then it'll stay that way.

Visual bug(s) fixed!

H.264 MBAFF muxing still fails..... hope you can support it soon :(

mkvmerge v2.0.2 ('You're My Flame') built on Feb 21 2007 23:40:43
'I:\cap\pride.h264': Using the AVC/h.264 ES demultiplexer.
'I:\cap\pride.ac3': Using the AC3 demultiplexer.
Track 0 of 'I:\cap\pride.h264': Extracted the aspect ratio information from the MPEG-4 layer 10 (AVC) video data and set the display dimensions to 1964/1080.
'I:\cap\pride.h264' track 0: Using the MPEG-4 part 10 ES video output module.
'I:\cap\pride.ac3' track 0: Using the AC3 output module.
The file 'G:\cap\pride.mkv' has been opened for writing.
'die' called: common.cpp/saferealloc() called from file src/common/common_memory.cpp, line 33: realloc() returned NULL for a size of 183654 bytes.

set the display dimensions to 1964/1080 <-- This makes no sense also, it's 1440x1080 which is displayed as 1920x1080.

Mosu

22nd February 2007, 16:09

The BBC file you (or someone else) gave me works fine. So how about you upload the pride.h264 file? I'm guessing that it is not an elementary stream but a transport stream. For those mkvmerge accidentally detects a h.264 elementary streams even though it isn't.

Anyway, I won't stick to using wxWidgets 2.6.3 because it causes other bugs.

bob0r

22nd February 2007, 16:53

Its the same .ts source as that sample

This is from BBC-HD also..... only difference: Its 13GB!

So thats the whole problem, same with Haali's dsmuxer... everything under around 4-5GB works fine, all above that goes wrong.

luxe.hd.ateme.ts and bbc.hd.ts <-- both work fine as 20mb files.

Note: NEW added sample was: luxe.hd.ateme.ts this is also H.264 MBAFF, the .ts can not be opened by elecard xmuxer pro, but mplayer was able to extract the raw.264 and raw.ac3

So in that case, you should still have the sample links.... get the raw h.264, and maybe you can figure out why a large file fails.....

.... Guess i got enough bandwidth anyway:
http://x264.nl/h.264.samples/

madshi

25th February 2007, 19:33

There will be no support for DD+ for the time being because a) I cannot find any specs, b) I don't have any means of playing back such a file (neither hardware nor software).
The spec is available here, I think:

http://www.atsc.org/standards/a52.html

Also I can send you an example DD+ stream, and I can get you going with playback though DirectShow, if you want. What do you think?

But maybe you want to wait until ffmpeg supports DD+? Don't know if that would save you time...

Dr.Khron

26th February 2007, 14:21

Mosu

26th February 2007, 14:43

Neither mmg nor mkvmerge is doing anything low level or interacting directly with the explorer. They only read and write files. What I could think of is that mkvmerge allocates too much memory which would indicate a memory hole somewhere. Maybe you could monitor memory usage during muxing with the task manager.

Mosu

26th February 2007, 14:51

The spec is available here, I think:

http://www.atsc.org/standards/a52.html

Also I can send you an example DD+ stream, and I can get you going with playback though DirectShow, if you want. What do you think?

But maybe you want to wait until ffmpeg supports DD+? Don't know if that would save you time...

Haali has also sent me the specs. Sample files are always welcome. DirectShow playback is nice to have, but not exactly helping because I usually develop on Linux. Developing on Windows is always a lot slower for me.

foxyshadis

27th February 2007, 06:05

MKVMerge GUI is causing my Windows Explorer to crash!

Pretty much anytime I mux an MKV, halfway through the process, my Windows Explorer crashes, closing all of my open windows, and making most of my system tray dissapear. The only fix is to reboot.

Seems like a conflict of some kind... any ideas what might be conflicting with MKVMerge GUI?
I bet you have some kind of shell extension that monitors mkv files, and crashes when it tries to read it while it's still being written. Probably matroskaprop, possibly haali's, but I don't think his is that badly behaved.

Check with this:
http://www.nirsoft.net/utils/shexview.html

Mosu

2nd March 2007, 16:42

Something for you guys to play with:

2007-03-02 Moritz Bunkus <moritz@bunkus.org>

* mkvmerge: new feature: Added support for EAC3 tracks in MPEG
program streams.

* mkvmerge: new feature: Added support for EAC3/DD+ (Dolby Digital
Plus) files and tracks (raw EAC3 files or inside Matroska with
CodecID A_EAC3).

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.0.2-build20070302-1.rar

Note that I still don't have a working playback solution here, so this is reeeeally untested. You will need the latest version of Haali's splitter of course.

madshi

2nd March 2007, 18:15

Thanks very much - Mosu!!! :)

I've just tested to mux an external EAC3 track into an already existing MKV file which was created by Haali's Matroska Muxer. Here are my results:

(1) I'm once again getting a few of the following warnings:

"Warning: pr_generic.cpp/generic_packetizer_c::add_packet(): timecode < last_timecode (00:59:30.600 < 00:59:30.667) for 1 of 'D:\test.mkv'. This should not have happened. Please contact the author with this error/warning message, a description of what you were trying to do, the command line used and which operating system you are using. Thank you."

Interestingly the first warning is at *exactly* the half of the movie (but not at the timecode where the two EVOs were splitted).

Mosu, does this warning have any practical meaning? Does it mean I should trash the new MKV because there's a glitch in it? If yes, is the glitch only in the new MKV or also in the original one? FWIW, I've checked the video at the 3 places the warnings mentioned and didn't notice any glitches. Does that mean I can safely ignore the warnings?

Besides, I'm always getting these warnings, if I remux one of the MKV files which were created by EVO -> Haali's Matroska Muxer. So this is not a problem related to the new EAC3 support. Maybe Haali's Matroska Muxer does something wrong?

(2) Muxing of the EAC3 track generally seems to work, at least I got no crashes, the file size seems to be right and the track is properly listed in MPC. Unfortunately I cannot really test whether the sound plays, because Haali's Media Splitter reports the EAC3 track in such a way that none of my EAC3 capable DirectShow filters can connect. I guess that's a problem in the Haali Media Splitter, cause the same thing happens if I use Haali's Media Splitter directly on EVO files or on MKV files with EAC3 in them created by Haali's Matroska Muxer.

madshi

2nd March 2007, 18:27

P.S: I'm not sure whether 0xeac3 is the correct way to sign the track. I think rather not.

Henrikx

2nd March 2007, 19:49

THX Mosu !!!

Mosu

2nd March 2007, 20:12

(1) I'm once again getting a few of the following warnings:

"Warning: pr_generic.cpp/generic_packetizer_c::add_packet(): timecode < last_timecode (00:59:30.600 < 00:59:30.667) for 1 of 'D:\test.mkv'. This should not have happened. Please contact the author with this error/warning message, a description of what you were trying to do, the command line used and which operating system you are using. Thank you."

Interestingly the first warning is at *exactly* the half of the movie (but not at the timecode where the two EVOs were splitted).

Mosu, does this warning have any practical meaning? Does it mean I should trash the new MKV because there's a glitch in it? If yes, is the glitch only in the new MKV or also in the original one? FWIW, I've checked the video at the 3 places the warnings mentioned and didn't notice any glitches. Does that mean I can safely ignore the warnings?

Yes, if there are no problems watching the file (these warnings only apply to video tracks) then you can ignore them. Actually I've disabled the warning this afternoon (after having uploaded the current build though). It was meant for myself for detecting errors in mkvmerge. However, due to the nature of video track timecodes especially with advanced codecs this warning is more often simply bogus and can be ignored. It usually unsettles users, that's why I'm removing it.

Besides, I'm always getting these warnings, if I remux one of the MKV files which were created by EVO -> Haali's Matroska Muxer. So this is not a problem related to the new EAC3 support. Maybe Haali's Matroska Muxer does something wrong?

Not necessarily :)

(2) Muxing of the EAC3 track generally seems to work, at least I got no crashes, the file size seems to be right and the track is properly listed in MPC. Unfortunately I cannot really test whether the sound plays, because Haali's Media Splitter reports the EAC3 track in such a way that none of my EAC3 capable DirectShow filters can connect. I guess that's a problem in the Haali Media Splitter, cause the same thing happens if I use Haali's Media Splitter directly on EVO files or on MKV files with EAC3 in them created by Haali's Matroska Muxer.

Ok, thanks for the feedback. I can use graphedit and connect Haali's splitter with the Intervideo Audio Decoder and with the Dump filter; this works with "EVO-to-MKV-with-Haali" file as well as with a "EAC3-to-MKA-with-mkvmerge" file. The results are byte identical, so I'm pretty confident that I haven't screwed up completely ;)

P.S: I'm not sure whether 0xeac3 is the correct way to sign the track. I think rather not.

I don't quite understand what you mean.

madshi

2nd March 2007, 20:25

Yes, if there are no problems watching the file (these warnings only apply to video tracks) then you can ignore them. Actually I've disabled the warning this afternoon (after having uploaded the current build though). It was meant for myself for detecting errors in mkvmerge. However, due to the nature of video track timecodes especially with advanced codecs this warning is more often simply bogus and can be ignored. It usually unsettles users, that's why I'm removing it.
Thank you for the explanation.

Ok, thanks for the feedback. I can use graphedit and connect Haali's splitter with the Intervideo Audio Decoder and with the Dump filter; this works with "EVO-to-MKV-with-Haali" file as well as with a "EAC3-to-MKA-with-mkvmerge" file. The results are byte identical, so I'm pretty confident that I haven't screwed up completely ;)
I believe the Dump filter eats whatever you throw at it... :) But I can not for the life of me connect Haali's splitter with the Intervideo Audio Decoder. Maybe you have a newer version of the Intervideo Audio Decoder than I have? Or do you have a non-public newer build of Haali's splitter?

I don't quite understand what you mean.
If I try to open a MKV file with an EAC3 track in it, MPC sais this:

"Media Type 0:
--------------------------
Audio: 0xeac3 48000Hz 6ch"

I thought "0xeac3" was what Haali reported as the audio format. I have a filter which can connect demuxed EAC3 files to the Intervideo Audio Decoder and I believe to remember that I saw it reporting 0xac3 and not 0xeac3. But I might be totally wrong. I'm not really an expert in this area...

Mosu

2nd March 2007, 22:43

I believe the Dump filter eats whatever you throw at it... :) But I can not for the life of me connect Haali's splitter with the Intervideo Audio Decoder. Maybe you have a newer version of the Intervideo Audio Decoder than I have? Or do you have a non-public newer build of Haali's splitter?

Yeah, though I think that Haali only changed a bug with the Matroska CodecID in it. It's http://haali.cs.msu.ru/mkv/mkx.I.2.exe The InterVideo AD is the one you've sent me.

madshi

3rd March 2007, 11:05

Yeah, though I think that Haali only changed a bug with the Matroska CodecID in it. It's http://haali.cs.msu.ru/mkv/mkx.I.2.exe
Great - thanks for the link!

I can now confirm that EAC3 support in your latest mkvtoolnix version is fully working! At least everything works fine in my first test with one movie.

:thanks:

madshi

3rd March 2007, 11:08

* mkvmerge: new feature: Added support for EAC3 tracks in MPEG program streams.
I'm wondering: Does that mean that EVO is "officially" supported by mkvtoolnix now?

Mosu

3rd March 2007, 12:29

No :) Neither VC1 nor h264 can be read from MPEG program streams yet.

madshi

3rd March 2007, 12:53

No :) Neither VC1 nor h264 can be read from MPEG program streams yet.
Ok, but are MPEG2 and AC3 and EAC3 officially supported in EVO files? I'm asking because after reading your comment about adding EAC3 support to MPEG program streams, yesterday I tried to drop a little MPEG2/AC3 evo into mmg and it seemed to work just fine. However, the resulting MKV was too short. It was only 2-3 minutes instead of 6 minutes and the file size was also short.

Anyway, if this is not supposed to work yet, just ignore my post... :)

Mosu

3rd March 2007, 13:50

I know that there are several issues with the MPEG PS reader in mkvtoolnix. I want to improve it during the next days. The goal is definitely to have at least MPEG-2 and EAC3 working properly, maybe even VC-1.

madshi

3rd March 2007, 13:56

Thank you. Your continued work on mkvtoolnix is greatly appreciated!

Mosu

3rd March 2007, 13:57

BTW: Could you please upload that EVO file? I definitely need more test files, especially ones on which mkvmerge chokes.

madshi

3rd March 2007, 14:13

BTW: Could you please upload that EVO file? I definitely need more test files, especially ones on which mkvmerge chokes.
The Departed Trailer from here stalls mkvmerge:

ftp://mplayerhq.hu/MPlayer/samples/evob/

I'll see if I can find more problematic evo files.

Mosu

3rd March 2007, 16:20

I know that the Departed trailer chokes mkvmege; I'm working on fixing it. Departed is also a VERY strange file because the packet IDs indicate "MPEG-2 video" but there's no sequence header found. Not even mplayer can play that file.

Haali

3rd March 2007, 17:31

It has H.264 in stream 0xe2.

Gusar

3rd March 2007, 18:16

Not even mplayer can play that file.

It can:mplayer -psprobe 100000 Deprated\ Trailer.EVO

Mosu

3rd March 2007, 18:21

I see. Thanks for the info, that should make fixing mkvmerge easier :)

DeepBeepMeep

5th March 2007, 12:35

There is a tremendous opportunity to boost even more Matroska polularity at the moment since it is the only container that can easily contain VC1 and DD+ thanks to recent progress made on mkvtoolnix and Haali filter. With a complete and simple solution to backup HDDVD and BluRay the Divx success is not far way...

Potential bug report:
-------------------

I don't know if this a bug. I have used HDdVD Evo demux on the second part file of the HDDVD Total Recall to extract the DTS HD track. If I try then to mux it inside a mkv file use mkvtoolnix.
First I have got tons of "Warning: dts_packetizer: skipping XXX bytes " which is mkvtoolnix ignoring the HD part of the DTS track. That's fine with me since there are so many of them the warning log window which keeps all the history gets slower and slower. There should be a way to ignore these types of warning. In order to obtain a fast mux I use the command line.

Then 2/3 in the process I have the warning below:

----------------
...
Warning: dts_packetizer: skipping 780 bytes (no valid DTS header found). This mi
ght make audio/video go out of sync, but this stream is damaged.
DTS header information changed! - New format:
DTS Frame Header Information:
Frame Type : normal
CRC available : no
Frame Size : PCM core samples=32*97=3104, 0.000723 milliseconds, 204
8 byte
Audio Channels : -1 ES, arrangement: unknown (user defined)
Core sampling frequency: 4294967295
Transmission_bitrate : 32000
Embedded Down Mix : no
Embedded Dynamic Range : no
Embedded Time Stamp : no
Embedded Auxiliary Data: no
HDCD Master : yes
Extended Coding : yes, but unknown
Audio Sync in sub-subs : yes
Low Frequency Effects : yes, interpolation factor 64
Predictor History used : no
Multirate Interpolator : non perfect
Encoder Software Vers. : 7
Copy History Bits : 2
Source PCM Resolution : 16
Front Encoded as Diff. : yes
Surr. Encoded as Diff. : yes
Dialog Normaliz. Gain : -13
Warning: dts_packetizer: skipping 794 bytes (no valid DTS header found). This mi
ght make audio/video go out of sync, but this stream is damaged.
Warning: 'E:\L1_mainMovie.DTSHD.stream.01.mpa' track 0: The current packet's tim
ecode is smaller than that of the previous packet. This usually means that the s
ource file is a Matroska file that has not been created 100% correctly. The time
codes of all packets will be adjusted by 1542692ms in order not to lose any data
. This may throw A/V sync off, but that can be corrected with mkvmerge's "--sync
" option. If you already use "--sync" and you still get this warning then do NOT
worry -- this is normal. If this error happens more than once and you get this
message more than once for a particular track then either is the source file bad
ly mastered, or mkvmerge contains a bug. In this case you should contact the aut
hor Moritz Bunkus <moritz@bunkus.org>.
DTS header information changed! - New format:
DTS Frame Header Information:
Frame Type : normal
CRC available : no
Frame Size : PCM core samples=32*16=512, 10.666667 milliseconds, 201
2 byte
Audio Channels : 5, arrangement: C, L, R, SL, SR (center, left, right, s
urround-left, surround-right)
Core sampling frequency: 48000
Transmission_bitrate : 1536000
Embedded Down Mix : no
Embedded Dynamic Range : no
Embedded Time Stamp : no
Embedded Auxiliary Data: yes
HDCD Master : no
Extended Coding : no
Audio Sync in sub-subs : yes
Low Frequency Effects : yes, interpolation factor 64
Predictor History used : yes
Multirate Interpolator : non perfect
Encoder Software Vers. : 7
Copy History Bits : 1
Source PCM Resolution : 16
Front Encoded as Diff. : no
Surr. Encoded as Diff. : no
Dialog Normaliz. Gain : 0
Warning: dts_packetizer: skipping 730 bytes (no valid DTS header found). This mi
ght make audio/video go out of sync, but this stream is damaged.

--------------

mkvtoolnix has incorrectly detected a change in the DTS audio track, then it switches back but add a huge delay. The consequence is that playback after two thirds of the file gives no sound and opening the mkv file takes much more time.

It could be a glitch with HD DVD Evo Demux or a bug in the detection algorithm of mkvtoolnix which instead of skipping the HD part of the DTS stream interprets it as an audio track change.

In any case I think an easy solution could be to ignore audio track change with incorrect audio channels (here -1), this would make mkvtoolnix much more resilient to damage sources.

Anyway, thanks for your great work

Mosu

5th March 2007, 13:06

2007-03-05 Moritz Bunkus <moritz@bunkus.org>

* mkvmerge: new feature: Added support for handling AVC/h.264
tracks in MPEG program streams.

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.0.2-build20070305-1.rar

At least it works with 'Departed Trailer.evo'.

Mosu

5th March 2007, 13:14

I don't know if this a bug. I have used HDdVD Evo demux on the second part file of the HDDVD Total Recall to extract the DTS HD track. If I try then to mux it inside a mkv file use mkvtoolnix.

mkvmerge does not yet support DTS HD tracks. If it thinks that it is DTS then you're on your own at the moment.

First I have got tons of "Warning: dts_packetizer: skipping XXX bytes " which is mkvtoolnix ignoring the HD part of the DTS track. That's fine with me since there are so many of them the warning log window which keeps all the history gets slower and slower. There should be a way to ignore these types of warning. In order to obtain a fast mux I use the command line.

You should get the best speed by redirecting the output to another file, e.g.

mkvmerge ... -o output.mkv input.evo ... > log.txt

While I agree that a feature to limit such a flood of message would be desirable I won't spend time on it. The little time I do have goes to improving EVO support in general.

Then 2/3 in the process I have the warning below:
...
Warning: 'E:\L1_mainMovie.DTSHD.stream.01.mpa' track 0: The current packet's timecode is smaller than that of the previous packet.
...
mkvtoolnix has incorrectly detected a change in the DTS audio track, then it switches back but add a huge delay. The consequence is that playback after two thirds of the file gives no sound and opening the mkv file takes much more time.

Hmm, interesting. Can you upload that file to my FTP server? The problem with EVO support is that I have virtually no access to such files except for the ones you guys provide.

Mosu

5th March 2007, 13:48

* mkvmerge: enhancement: Fixed the MPEG PS reader so that it will just skip blocks whose headers it cannot parse instead of aborting.

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.0.2-build20070305-2.rar

Madshi: This build works with DELSCENE4.EVO. Could you please test it against the other files you have?

madshi

5th March 2007, 18:46

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.0.2-build20070305-2.rar

Madshi: This build works with DELSCENE4.EVO. Could you please test it against the other files you have?
Works with all 3. Thanks for the speedy fix... :)

madshi

5th March 2007, 18:58

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.0.2-build20070305-1.rar

At least it works with 'Departed Trailer.evo'.
Thank you!! :) Am just trying that with Equilibrium. Here's how it behaves:

(1) Detects video and audio just fine.
(2) When starting to mux, there's a freeze for half a minute or so.
(3) Then muxing starts and looks promising.
(4) There's a long freeze after 500MB are written.
(5) It continues after a while, but the GUI is always not responding and progress is extremely slow. Now at 750MB after several minutes. Normally it just takes a few seconds to get that far.

Basically it seems to work, but it's extremely slow and the GUI is not responding at all.

I'm sorry, but I cannot send you this evo, cause it's a real movie (would be illegal to send you) and besides it's 17GB.

DeepBeepMeep

5th March 2007, 19:06

Mosu,

I have uploaded the DtsHD track on your ftp site. It is a huge file named "DtsHDTrack.dts". It seems something went wrong and obviously only 90% of the file is there. Hopefully, the glitch is there and should occur towards the end of the file. I happened when I had muxed it with a mkv file that contained already a VC1 file (generated with Haali Filter).

Thanks for your help

Mosu

5th March 2007, 19:41

Thank you!! :) Am just trying that with Equilibrium. Here's how it behaves:

(1) Detects video and audio just fine.
(2) When starting to mux, there's a freeze for half a minute or so.
(3) Then muxing starts and looks promising.
(4) There's a long freeze after 500MB are written.
(5) It continues after a while, but the GUI is always not responding and progress is extremely slow. Now at 750MB after several minutes. Normally it just takes a few seconds to get that far.

Basically it seems to work, but it's extremely slow and the GUI is not responding at all.

I'm sorry, but I cannot send you this evo, cause it's a real movie (would be illegal to send you) and besides it's 17GB.

What kind of a video track is this? MPEG-2? I know that both MPEG-1/2 and AVC can be slow, and I've witnessed them being especially slow for EVO files. I will probably have to rewrite the complete MPEG-1/2 code. While it uses a nice object oriented approach it is dead slow ;)

That the GUI is not responding is indeed bad, but I won't fix this completely (way too much work to figure out how to do this... multithreading etc etc, a lot of topics that I haven't covered with wxWidgets before).

madshi

5th March 2007, 22:54

What kind of a video track is this?
It's H.264/AVC.

That the GUI is not responding is indeed bad, but I won't fix this completely (way too much work to figure out how to do this... multithreading etc etc, a lot of topics that I haven't covered with wxWidgets before).
Moving the GUI to another thread would probably be quite complicated. But I think moving just the mkvmerge encapsulation to a secondary thread should be rather easy. With win32 APIs (using Send/PostMessage for thread safe communication between the threads) at least it would.

But anyway, it's not really necessary IMHO. The responsiveness it normally quite acceptable. It's only this specific case with the 17GB H.264 EVO where the responsiveness was not so good, anymore.

madshi

6th March 2007, 08:07

Let mkvmerge run through Equilibrium last night. Today morning the progress bar had stopped at 65% and the status window sais:

mkvmerge v2.0.2 ('You're My Flame') built on Mar 5 2007 13:45:56
'D:\Equilibrium.evo': Using the MPEG PS demultiplexer.
'D:\Equilibrium.evo' track 0: Using the MPEG-4 part 10 ES video output module.
The file 'D:\Equilibrium.mkv' has been opened for writing.
'die' called: common.cpp/safemalloc() called from file src/common/mpeg4_common.cpp, line 1046: malloc() returned NULL for a size of 139610 bytes.

Mosu

6th March 2007, 09:16

Let mkvmerge run through Equilibrium last night. Today morning the progress bar had stopped at 65% and the status window sais:

'die' called: common.cpp/safemalloc() called from file src/common/mpeg4_common.cpp, line 1046: malloc() returned NULL for a size of 139610 bytes.

Hmm, sounds like a serious memory leak. I'll have to see if I can find some other EVO which triggers this memory leak.

DeepBeepMeep

6th March 2007, 09:35

In order to give you idea how the DTSHD track I mentioned before was mixed in the original EVO file I have uploaded a short sample of the EVO file (VC1WithDTSHD.EVO)

It is an interesting file as wells since mkvtoolnix won't see any track in it for the moment while there are in fact one video VC1 track and three DTSHD tracks (one is 5.1 and two 2.0)

Mosu

6th March 2007, 15:31

In order to give you idea how the DTSHD track I mentioned before was mixed in the original EVO file I have uploaded a short sample of the EVO file (VC1WithDTSHD.EVO)

Thanks for the upload.

It is an interesting file as wells since mkvtoolnix won't see any track in it for the moment while there are in fact one video VC1 track and three DTSHD tracks (one is 5.1 and two 2.0)

Quite natural considering mkvmerge supports neither VC1 nor DTSHD at the moment :)

DeepBeepMeep

6th March 2007, 16:16

Thanks for the upload.

Quite natural considering mkvmerge supports neither VC1 nor DTSHD at the moment :)

My pleasure. If this can give some inspiration on how to support demuxing EVO with VC1 (which is the video codec the most used with HDDVD) this would make turning an EVO into a MKV file only a one click process.

On a side note, when mkvtoolnix parses an EVO file and finds some DD+ tracks for instance it seems to order them randomly. This can be a bit confusing and can cause trouble when trying to merge two evo files using mkvtoolnix, it seems there is a proper order (based on the PID?) that can be detected by EvoDemux.exe (http://pel.hu/down/EVOdemux.exe) or by evob_demux (http://www.w6rz.net/evob_demux.zip ).

ToS_Maverick

6th March 2007, 21:23

@mosu

got another issue for you, hope you have some time to look at it ;)

my workflow as described in another thread (http://forum.doom9.org/showthread.php?p=966425#post966425) is:
Pro7 HD Transport Stream => Demux with Graphedit (Haali Media Splitter => Haali Matroska Muxer) => spilt with mkvmerge GUI (the "unwanted" scenes)

mkvmerge commanline looks like this:

"mkvmerge" -o "F:\Video\DVB\Baby\baby test.mkv" --language 1:eng --default-track 1:yes --display-dimensions 1:1920x1080 --language 2:eng --default-track 2:yes -a 2 -d 1 -S "F:\Video\DVB\Baby\baby.mkv" --track-order 0:1,0:2 --split timecodes:73s,1806s,2365s,3996s,4617s,5800s,6399s,7624s,8180s,9772s

now i wanted to further split the splitted file, to send a sample to neuron2. i set mkvmerge to split after 20M and got this result:

mkvmerge v2.0.2 ('You're My Flame') built on Feb 21 2007 23:40:43
'F:\Video\DVB\Baby\baby splitted-002.mkv': Using the Matroska demultiplexer.
'F:\Video\DVB\Baby\baby splitted-002.mkv' track 1: Using the MPEG-4 part 10 (AVC) video output module.
'F:\Video\DVB\Baby\baby splitted-002.mkv' track 2: Using the AC3 output module.
The file 'F:\Video\DVB\Baby\baby test splitted-002-001.mkv' has been opened for writing.
'die' called: bref_packet == NULL. Wanted bref: -40000000. Contents of the queue:
Packet 0, timecode 0, bref -1, fref -1
Packet 1, timecode 65000000, bref -1, fref -1
Packet 2, timecode 97000000, bref -1, fref -1
Packet 3, timecode 120000000, bref -40000000, fref -1
Packet 4, timecode 40000000, bref 120000000, fref -1
Packet 5, timecode 80000000, bref 40000000, fref -1
Packet 6, timecode 129000000, bref -1, fref -1
Packet 7, timecode 160000000, bref 80000000, fref -1
Packet 8, timecode 161000000, bref -1, fref -1
Packet 9, timecode 193000000, bref -1, fref -1
Packet 10, timecode 225000000, bref -1, fref -1
Packet 11, timecode 257000000, bref -1, fref -1
Packet 12, timecode 280000000, bref 160000000, fref -1
Packet 13, timecode 200000000, bref 280000000, fref -1
Packet 14, timecode 240000000, bref 200000000, fref -1
Packet 15, timecode 289000000, bref -1, fref -1
Packet 16, timecode 321000000, bref -1, fref -1
Packet 17, timecode 353000000, bref -1, fref -1
Packet 18, timecode 385000000, bref -1, fref -1
Packet 19, timecode 400000000, bref -1, fref -1
Packet 20, timecode 320000000, bref 400000000, fref -1
Packet 21, timecode 360000000, bref 320000000, fref -1
Packet 22, timecode 417000000, bref -1, fref -1
Packet 23, timecode 449000000, bref -1, fref -1
Packet 24, timecode 481000000, bref -1, fref -1
Packet 25, timecode 513000000, bref -1, fref -1
Packet 26, timecode 520000000, bref 360000000, fref -1
Packet 27, timecode 440000000, bref 520000000, fref -1
Packet 28, timecode 480000000, bref 440000000, fref -1
Packet 29, timecode 545000000, bref -1, fref -1
Packet 30, timecode 577000000, bref -1, fref -1
Packet 31, timecode 609000000, bref -1, fref -1
Packet 32, timecode 640000000, bref -1, fref -1
Packet 33, timecode 560000000, bref 640000000, fref -1
Packet 34, timecode 600000000, bref 560000000, fref -1
Packet 35, timecode 641000000, bref -1, fref -1
Packet 36, timecode 673000000, bref -1, fref -1
Packet 37, timecode 705000000, bref -1, fref -1
Packet 38, timecode 737000000, bref -1, fref -1
Packet 39, timecode 760000000, bref 600000000, fref -1
Packet 40, timecode 680000000, bref 760000000, fref -1
Packet 41, timecode 720000000, bref 680000000, fref -1
Packet 42, timecode 769000000, bref -1, fref -1
Packet 43, timecode 801000000, bref -1, fref -1
Packet 44, timecode 833000000, bref -1, fref -1
Packet 45, timecode 865000000, bref -1, fref -1
Packet 46, timecode 880000000, bref 720000000, fref -1
Packet 47, timecode 800000000, bref 880000000, fref -1
Packet 48, timecode 840000000, bref 800000000, fref -1
Packet 49, timecode 897000000, bref -1, fref -1
Packet 50, timecode 929000000, bref -1, fref -1
...

it happens with all splitted files, except the first one!

on Nemo, it only happens on a file that i demuxed with mkvextract, all other files work.

on tears of the sun, it happens after splitting... really inconsitent phenomenon and hard to reproduce.

hope you can help me on this one!

foxyshadis

7th March 2007, 13:16

Mosu, would you care to look at the VFR problem thread (http://forum.doom9.org/showthread.php?t=123097) in this forum, to see whether the problem is in mkvmerge and whether it can be fixed there?

Mosu

8th March 2007, 17:00

2007-03-08 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: The MPEG program stream reader will now sort the tracks it finds first by their type (video > audio > subs) and then by their stream ID.
* mkvmerge: Disabled the support for DTS tracks in MPEG program streams because DTS HD is not supported yet.
* mkvmerge: enhancement: Implemented a major speed-up for reading

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.0.2-build20070308-1.rar

And sorry Maverick & foxyshadis, I'm not in the mood for bugfixing such problems at the moment.

madshi

8th March 2007, 17:13

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.0.2-build20070308-1.rar
Thanks!

Eragon4ever

8th March 2007, 17:18

* mkvmerge: enhancement: Implemented a major speed-up for reading

... MPEG-1/2 and AVC/h.264 tracks from MPEG program streams.

Mosu

8th March 2007, 17:34

Indeed. I f'cked up a simple "copy & paste" :)

Henrikx

8th March 2007, 17:50

:thanks: Mosu

DeepBeepMeep

8th March 2007, 19:10

Great News! Thanks Mosu!

Well in fact, DTS HD was somewhat already supported beside the bug I have reported which didn't occur on all the streams I have tested. What was supported with DTS HD was the conversion from DTS HD to DTS by ignoring the "HD" part. In fact if you plan to add DTS HD support, an option to keep either the whole DTS HD packets or only their DTS packets could be convenient since there aren't many DTS HD decoders for the moment.

madshi

10th March 2007, 16:06

* mkvmerge: enhancement: Implemented a major speed-up for reading MPEG-1/2 and AVC/h.264 tracks from MPEG program streams.
I can gladly confirm that the Equilibrium H.264 EVO -> MKV muxing performance was greatly improved! :)

However, it still fails in the middle of the movie. I've done some further checks and attached you'll find a screenshot of the memory consumption during Equilibrium muxing. You'll notice two things:

(1) The memory consumption increases and decreases in time intervals of different length.
(2) The bottom line of the memory consumption grows over time.

So because of (2) I think there is a memory leak somewhere in mkvmerge. I'm not sure, though, whether the memory leak is really the main problem. It's a problem, but not the only one. From what I can see, Equilibrium has some INSANE GOP distances. It seems to me that mkvmerge is reading one complete GOP into RAM and only then writes it to harddisk. Usually that's a nice approach, but with Equilibrium the GOP distances are so big that it's getting dangerous. I've seen memory consumption go to >500MB with a large GOP in Equilibrium - and that's just in the beginning of the movie. There may be even bigger GOPs later in the movie. Another thing I noticed is that the GUI seems to updated only once every time when a GOP was fully read in. That would explain why the GUI is so much less responsive when muxing Equilibrium compared to other movies, because with Equilibrium the GOP distances are so much longer than with any other movie I've ever seen...

Mosu

10th March 2007, 16:37

I can gladly confirm that the Equilibrium H.264 EVO -> MKV muxing performance was greatly improved! :)

Good to hear.

However, it still fails in the middle of the movie. I've done some further checks and attached you'll find a screenshot of the memory consumption during Equilibrium muxing. You'll notice two things:

(1) The memory consumption increases and decreases in time intervals of different length.
(2) The bottom line of the memory consumption grows over time.

I cannot look at the picture yet because it's still awaiting authorization, but (2) is necessary or at least normal. A slow but steady increase in memory consumption will always happen because mkvmerge needs to keep data in memory that it can only write at the end of the muxing process (e.g. the index).

From what I can see, Equilibrium has some INSANE GOP distances. It seems to me that mkvmerge is reading one complete GOP into RAM and only then writes it to harddisk.

True, and this cannot be avoided. Especially with codecs with out-of-order timecodes (which all modern video codecs are; MPEG-1/-2, MPEG-4, AVC...) because you cannot assign timecodes correctly until you've found the next key frame.

Usually that's a nice approach, but with Equilibrium the GOP distances are so big that it's getting dangerous. I've seen memory consumption go to >500MB with a large GOP in Equilibrium - and that's just in the beginning of the movie.

Like I've said, it's not only "a nice approach", it's really necessary.

There may be even bigger GOPs later in the movie. Another thing I noticed is that the GUI seems to updated only once every time when a GOP was fully read in.

Yep. mmg only processes user interaction when it gets input from mkvmerge (e.g. a warning, any other message, or the progress report). This can only be solved with proper multithreading.

foxyshadis

10th March 2007, 16:49

You can't figure timecodes as soon as you hit a P frame? Because I thought you could figure the timestamps for the previous segment as soon as you hit the next P frame. Graphically:

IPBBBPBBBPI
IPBBBPBBBPI
IPBBBPBBBPI
IPBBBPBBBPI
IPBBBPBBBPI
IPBBBPBBBPI
IPBBBPBBBPI
IPBBBPBBBPI
....
Grey: Unread. Red: Read, unknown timestamp. Blue: Known timestamp and written.

As far as I know there's no mpeg codecs where b-frames can be timed after the next P frame.

issa

10th March 2007, 19:43

NEED HELP!!!
I try to merge a movie with 3 avi files and 3 srt subtitle files into a
single mkv file using mmg with append function.
However, after finished merging. I found only first two srt files get merge into the mkv file. I extract the the subtitle form the mkv file and found the last subtitle is same as the last subtitle in the second srt file. The whole 3rd srt file are missing.
The video and audio are pefectly merged.
Is there any limitation on mkvmerge for srt supporting?

Mosu

10th March 2007, 20:06

No, there isn't. What's the command line?

akupenguin

11th March 2007, 09:31

As far as I know there's no mpeg codecs where b-frames can be timed after the next P frame.
H.264 allows arbitrary frame orders. It's not based on frame types at all, even the IDR-frame doesn't have to be the first frame in display order. A frame could be decoded at one time, and then displayed 500 frames later.
Now, there's an optional field in the SPS that says how much buffering a decoder will need to do, and typically it's only 1 or 2 frames. But that's only the typical case, not the limit.

bob0r

11th March 2007, 19:05

Hmm, sounds like a serious memory leak. I'll have to see if I can find some other EVO which triggers this memory leak.

Again.... i think this is a problem with LARGE files.... rather than a file type:

Again my BBC-HD H.264 MBAFF file

mkvmerge v2.0.2 ('You're My Flame') built on Mar 8 2007 16:56:40
'G:\cap\test.h264': Using the AVC/h.264 ES demultiplexer.
'G:\cap\test.ac3': Using the AC3 demultiplexer.
Track 0 of 'G:\cap\test.h264': Extracted the aspect ratio information from the MPEG-4 layer 10 (AVC) video data and set the display dimensions to 1964/1080.
'G:\cap\test.h264' track 0: Using the MPEG-4 part 10 ES video output module.
'G:\cap\test.ac3' track 0: Using the AC3 output module.
The file 'I:\cap\test.mkv' has been opened for writing.
'die' called: common.cpp/saferealloc() called from file src/common/common_memory.cpp, line 33: realloc() returned NULL for a size of 204220 bytes.

test.h264 11.6 GB (12,551,775,186 bytes)
test.ac3 244 MB (256,423,415 bytes)

Haali's muxer has problems with big files also....

Shall i upload these files so you guys can test and fix this once and for all?

Mosu

11th March 2007, 19:24

I'd really appreciate that. I've tried getting my hands on such big EVO files but without success so far :(

bob0r

11th March 2007, 19:27

This is from a BBC-HD .ts file, also good? upload to that ftp? Mind if i rar it?

issa

12th March 2007, 02:23

Mosu,

I found the problem, and I had temp. fix for that.
Wait for your final fix on it.

Mosu

12th March 2007, 11:35

This is from a BBC-HD .ts file, also good? upload to that ftp? Mind if i rar it?

Yes, to my FTP server, please. You can surely RAR it.

Mosu

12th March 2007, 16:11

Issa: Thanks for the patch. I've only tried it with two or three files here myself, but it's OK for them (and definitely not OK without the patch), so I'm including it.

Here's a current build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.0.2-build20070312-1.rar

Okraml

12th March 2007, 19:33

aabxx

12th March 2007, 23:18

Taken from matroska-devel, oct. 2005 http://lists.matroska.org/pipermail/matroska-devel/2005-October/002756.html
***
- The Frames in the SimpleBlock have no duration. That means SimpleBlock is not suitable for VFR content (VFR video or Vorbis). Or we could fall back in using BlockGroup when the duration of the frames are not the default ones...
***

Does this mean --engage use_simpleblock should not be used when muxing ogg vorbis?

Mosu

13th March 2007, 09:41

Does this mean --engage use_simpleblock should not be used when muxing ogg vorbis?

No. This is not a problem due to two reasons:

Matroska specs say that the duration of a (simple) block is either the value of the BlockDuration element if present, or the value of the track's DefaultDuration element or the difference to the next block of the same track if neither a) nor b) is given. For Vorbis mkvmerge does not write a DefaultDuration element meaning that the duration is always the difference of the current and next timecodes for this track which is perfectly fine with simple blocks.
If a default duration is given and the current packet's duration is different than the default duration then mkvmerge writes a normal block, even if "--engage use_simpleblock" is turned on.

Mosu

13th March 2007, 11:04

I got a sample of an .avc file (20MB) that plays fine standalone, but not after muxing into a .mkv. Cause i have troubles uploading to your ftp, you can download the testfile here (http://depositfiles.com/files/690412).

:-) Okraml

That's an interesting file. MP4Box cannot import it correctly either (same playback problems as the Matroska file created with mkvmerge). Is there another application that can actually turn this file into a playable MP4 file?

Okraml

13th March 2007, 17:42

That's an interesting file. MP4Box cannot import it correctly either (same playback problems as the Matroska file created with mkvmerge). Is there another application that can actually turn this file into a playable MP4 file?

MP4Creator doesn't produce playable mp4 files too. But i got another testfile for you here (http://depositfiles.com/files/692849).

:-) Okraml

issa

13th March 2007, 18:06

zgx

13th March 2007, 21:49

I’m not sure this is the right thread but I’m badly in need of some Matroska muxing help.

I want to put a VC-1 video stream and a DD+ stream from a HD-DVD into a Matroska container. That I have done with the help of gdsmux and mkvmerge but the video seams to play too fast so I get serious audio sync problems. I have read some things about timecode files and I have tried to include a timecode file that looks like this (with the video stream):

# timecode format v1
assume 23.976

That didn’t help so I’m wondering if anyone here has any idea how I could get it to work properly?

madshi

13th March 2007, 22:28

zgx

13th March 2007, 23:12

I don't know gdsmux, but mkvtoolnix doesn't yet support VC-1 muxing. Personally, I'm using Haali's Media Splitter and Haali's Matroska Muxer to mux VC-1 streams into MKV and that works perfectly fine for me.Thanks I will give it a try. What makes it extra tricky is the DD+ as I don't think Haali's Muxer supports it yet.

I'm also thinking there could be something wrong with my playback setup. I get the same problems when I try to play a EVO file in ZoomPlayer.

madshi

14th March 2007, 08:30

Thanks I will give it a try. What makes it extra tricky is the DD+ as I don't think Haali's Muxer supports it yet.
Haali's latest version does fully support DD+ !

Mosu

14th March 2007, 09:24

I got a ogm/avi file have the audio track 0x674f when play with mplayer, and it can not play the audio. When I import it to mmg, it display unknown type. I found out that it is OGG_VORBIS_1. How can I force the mmg to set the fourcc of the audio track, since the option panel is gray out.

It's not possible. If mkvmerge says that a track is unknown or unsupported, then it is just that, not supported. Especially Vorbis-in-AVI. That's about the worst possible way of storing Vorbis. It's inefficient, completely hacky (because Vorbis is both variable frame rate and variable sample rate). I will never support it.

dragonle87

14th March 2007, 15:14

Hi, I have quite a few mkv files with audio out of sync when storing xvid to native mpeg-4 asp. The weird thing is all of these files play perfectly fine in mkv with vfw hack. So basically, is there a way to revert back the changes? If not, can you make it available in the next release? Cause I don't like going thru every single one of them to fix synchronization when they are originally in sync prior to muxing. You know, kind of like how you reintroduced the "--engage allow_avc_in_vfw_mode" hack, make a similar feature like "--engage allow_asp_in_vfw_mode" hack or "--unengage native_mpeg-4" ...well something to that effect. The crappy thing is I don't have the original a/v files prior to muxing in mkv nor do I like the fact of going thru the whole encoding process again.

btw, for playback, I use MPC (internal filters disabled) + ffdshow + Haali's splitter.

Mosu

14th March 2007, 15:23

issa

15th March 2007, 07:07

It's not possible. If mkvmerge says that a track is unknown or unsupported, then it is just that, not supported. Especially Vorbis-in-AVI. That's about the worst possible way of storing Vorbis. It's inefficient, completely hacky (because Vorbis is both variable frame rate and variable sample rate). I will never support it.

I found out that the file is ogm/ogg with renamed to avi extension.
However, I think the 0x674f is code OGG. Why the mmg said the audio track unknown? I have another ogm file that the mmg can detect the audio track as vorbis.

Mosu

15th March 2007, 08:12

I found out that the file is ogm/ogg with renamed to avi extension.
However, I think the 0x674f is code OGG. Why the mmg said the audio track unknown? I have another ogm file that the mmg can detect the audio track as vorbis.

Real OGM files with properly muxed Vorbis tracks are fully supported. AVI with OGG/Vorbis inside are not supported, and will not be supported. OGM files which use the ACM mode of storing audio (the same mode that you can store MP3 in OGM) for Vorbis are the same case as AVI with Vorbis -- no, they're even worse. And won't be supported either.

issa

15th March 2007, 08:39

Real OGM files with properly muxed Vorbis tracks are fully supported. AVI with OGG/Vorbis inside are not supported, and will not be supported. OGM files which use the ACM mode of storing audio (the same mode that you can store MP3 in OGM) for Vorbis are the same case as AVI with Vorbis -- no, they're even worse. And won't be supported either.

That's mean the 0x674f is the ID of OGG for ACM mode?

foxyshadis

15th March 2007, 08:45

Since these brain-dead files can't be that common, why not just use vdubmod or avimux gui to extract the audio track? You'll have to unencapsulate it then (probably by just deleting the header) and it should work after that.

issa

15th March 2007, 09:03

LeMoi

16th March 2007, 01:20

If a stretch AND a delay is applied on a sub track, which one is first applied ?

Rectal Prolapse

16th March 2007, 06:07

I am having trouble importing SRT files created by Pelican9's Supread.exe tool - is there something that needs to be added to the SRT file to make it recognizable by mkvmerge?

It starts and ends like this:

1
0:01:48.041 --> 0:01:50.442
Bloody kids.

2
0:02:36.890 --> 0:02:40.554
How fastidious you've become,
Wormtail.

...

1508
2:23:00.772 --> 2:23:04.538
-Harry will, won't you?
-Yeah. Every week.

1509
2:37:01.345 --> 2:37:03.336
[ENGLlSH]

Thanks.

Mosu

16th March 2007, 08:08

1
0:01:48.041 --> 0:01:50.442
Bloody kids.

The timestamps have to use "," as the decimal separator, not ".".

Edit: Or you could just use this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-2.0.2-20070316-1.rar

Mosu

16th March 2007, 08:09

If a stretch AND a delay is applied on a sub track, which one is first applied ?

If you mean the two components of the --sync switch: First the delay, then the stretch factor. The --delay argument is added last.

Rectal Prolapse

16th March 2007, 21:35

Thanks Mosu, MKVMergeGUI recognized it!

Okraml

16th March 2007, 23:21

@Mosu
Did you found out, whats wrong with the videofiles from this (http://forum.doom9.org/showthread.php?p=969420#post969420) and this (http://forum.doom9.org/showthread.php?p=969867#post969867) post?

Cause Haali Matroska Muxer doesn't work as well, i will post there too.

:-) Okraml

Mosu

16th March 2007, 23:42

No, not yet. I'll post when I know more, but that won't be for a couple of days.

DeepBeepMeep

17th March 2007, 16:29

I don't know if this has been already reported, but I have trouble merging a 3 part files that has been previously split using mkvmerge with the "link" options.

The file here is a matroska with MPEG2 + 2 AC3 audio tracks
Once the first file has been processed, I get a:
----------
'die' called: fref_packet == NULL. Wanted fref: -125000000. Contents of the queue:
Packet 0, timecode -1841054272, bref -1924054272, fref -1799054272
Packet 1, timecode -1776054272, bref -1, fref -1
Packet 2, timecode -1776054272, bref -1, fref -1
Packet 3, timecode -1744054272, bref -1, fref -1
Packet 4, timecode -1744054272, bref -1, fref -1
Packet 5, timecode -1712054272, bref -1, fref -1
Packet 6, timecode -1712054272, bref -1, fref -1
Packet 7, timecode -1680054272, bref -1, fref -1
Packet 8, timecode -1680054272, bref -1, fref -1
Packet 9, timecode -1674054272, bref -1799054272, fref -1
Packet 10, timecode -1758054272, bref -1799054272, fref -1674054272
Packet 11, timecode -1716054272, bref -1799054272, fref -1674054272
Packet 12, timecode -1648054272, bref -1, fref -1
Packet 13, timecode -1648054272, bref -1, fref -1
Packet 14, timecode -1632054272, bref -1, fref -1
Packet 15, timecode -1716054272, bref -1632054272, fref -125000000
Packet 16, timecode -1674054272, bref -1632054272, fref -125000000
Packet 17, timecode -1616054272, bref -1, fref -1
Packet 18, timecode -1616054272, bref -1, fref -1
Packet 19, timecode -1584054272, bref -1, fref -1
Packet 20, timecode -1584054272, bref -1, fref -1
Packet 21, timecode -1552054272, bref -1, fref -1
Packet 22, timecode -1552054272, bref -1, fref -1
Packet 23, timecode -1507054272, bref -1632054272, fref -1
----------

Mosu

18th March 2007, 09:56

Negative timecodes? Oh oh... Looks like mkvmerge has overflow issues somewhere. Can you give me some more details about the file? Like duration, how you created it etc.

DeepBeepMeep

18th March 2007, 13:32

If I rememeber correctly the files were created using mkvmerge with elementary streams. The MPEG2 stream has been extracted from a Bluray Disk using the xport tool. The movie is 1:30 minutes and spans around three 4.5Gb Files.
Note I have managed to merge them using Haali filter and Haali matroska filter so it seems the files are not corrupted.

I hope this helps

ToS_Maverick

18th March 2007, 14:29

@mosu: this errors look quite familiar to me, remeber :D

Mosu

18th March 2007, 16:19

Well, partially. In your case there were no negative timecodes involved, even though the error message is the same. Therefore the reason may or may not be the same.

LeMoi

19th March 2007, 00:08

If you mean the two components of the --sync switch: First the delay, then the stretch factor. The --delay argument is added last.

Is there a way to stretch, THEN delay, via command line ?

Mosu

19th March 2007, 09:59

No, there isn't.

bob0r

21st March 2007, 05:48

@Mosu

When will it be possible to mux .mkv to .mkv and fix nal-size to 4?

I muxed all my .mkv with nal-size 3, but Cyberlink H.264 decoder wont decode the video (so the file just stops at the beginning)

Mosu

21st March 2007, 08:31

It's done when it's done. Sorry, I can't give you a date.

LeMoi

22nd March 2007, 18:58

No, there isn't.
Can I make it a feature request ? :)

Mosu

22nd March 2007, 19:08

Sure you can, but it'll be veeery low on my priority list. It'll be best if you create a new bug in my Bugzilla system and set the severity to enhancement. That way I won't forget about it.

delacroixp

25th March 2007, 12:43

I've been encoding "Band of Brothers" an Mpeg-2, 720x576 (PAL) 16:9 movie... @ full 720x576 resolution...
using H264, AutoMKV, the ConstantQuality-CRF profile set to Q22 and the MKV container.

It encodes beautifully but refuses to play back at 1024x576, 16:9 DAR...
I can manually adjust my Zoom Player to 16:9 DAR and all is good.

AutoMKV does have modified AR and Anamorphic Muxing Options... but they don't seam to have any effect...
Buzzqw (http://forum.doom9.org/showpost.php?p=974816&postcount=1544) recommended that I try here... perhaps a little hands-on muxing with MkvMerge could do the trick.

Please help !

:thanks:

:) :D :eek:
Pascal

J_Darnley

25th March 2007, 23:12

Use the following switch with mkvmerge, but of course replace <track> with the number for the video track.

--display-dimensions <track>:1024x576

honai

26th March 2007, 14:52

I get the following errors/warnings:

Warning: pr_generic.cpp/generic_packetizer_c::add_packet(): timecode < last_timecode (00:59:30.600 < 00:59:30.667) for 1 of '...\Serenity\part1.mkv'. This should not have happened. Please contact the author Moritz Bunkus <moritz@bunkus.org> with this error/warning message, a description of what you were trying to do, the command line used and which operating system you are using. Thank you.

Warning: pr_generic.cpp/generic_packetizer_c::add_packet(): timecode < last_timecode (01:22:38.595 < 01:22:38.662) for 1 of '...\Serenity\part2.mkv'. This should not have happened. Please contact the author Moritz Bunkus <moritz@bunkus.org> with this error/warning message, a description of what you were trying to do, the command line used and which operating system you are using. Thank you.

Warning: pr_generic.cpp/generic_packetizer_c::add_packet(): timecode < last_timecode (01:48:27.859 < 01:48:27.926) for 1 of '...\Serenity\part2.mkv'. This should not have happened. Please contact the author Moritz Bunkus <moritz@bunkus.org> with this error/warning message, a description of what you were trying to do, the command line used and which operating system you are using. Thank you.

Command-line:

"mkvmerge" -o "...\Serenity\full.mkv" --language 1:eng --track-name "1:Video VC-1 1080p" --display-dimensions 1:1920x1080 -d 1 -A -S ...\Serenity\part1.mkv -d 1 -A -S +...\Serenity\part2.mkv --track-order 0:1 --append-to 1:1:0:1

(where "..." denotes the respective file path)

Source was demuxed with Haali's Splitter and Matroska Muxer straight from the .EVO files. Using Windows XP SP2.

Mosu

26th March 2007, 15:02

Concatenating h264 video is buggy at the moment, and I don't know when I'll be able to fix this.

madshi

26th March 2007, 15:04

@honai, here's the answer to your post:

http://forum.doom9.org/showthread.php?p=964902#post964902

honai

26th March 2007, 15:09

It's VC-1 not h.264 but thanks for the clarification. The resulting file plays just fine.

While I'm at it: I've demuxed the EAC3 tracks from the Serenity EVOs with EVODemux. How do I mux that into MKV? mkvmerge complains that the audio tracks were AVC ES streams, which is definitely wrong.

madshi

26th March 2007, 15:15

honai

26th March 2007, 15:22

Using the latest version from Mosu's signature, 2.0.2-1. Get message that the file type were AVC ES.

Mosu

26th March 2007, 15:38

EAC3 is only implemented in builds after 2.0.2-1 available for testing from http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/

delacroixp

26th March 2007, 19:17

Use the following switch with mkvmerge, but of course replace <track> with the number for the video track.

--display-dimensions <track>:1024x576
Very neat...

:thanks:

:) :D :eek:
Pascal

issa

28th March 2007, 09:10

When I try to convert a AVI file contain XviD/DivX with AC3/MP3 into MKV with "--engage native_mpeg4" option. The final MKV file will out of sync. If I conevrt a AVI file contain H.264/AVC with AC3/MP3 using the same option flag. The result file is fine.
I would like to ask if the un-sync problem on XviD/DivX with AC3/MP3 with "--engage native_mpeg4" is an expected behavior.

Mosu

28th March 2007, 13:25

Of course not :) Async audio/video from in-sync files is always a bug.

woah!

29th March 2007, 07:46

hi Mosu

this is probably a silly question but how do i set the frame rate to 23.976 when muxing out an EVO file to mkv ?

i use graphedit and plug in the splitter/muxer ok and it gives me a perfect result. but then when i add it to mkvmerge i get again a perfect mux with the ac3 audio but the video is set to 25frames when i check :( the option in mkvmerge to set the fps is greyed out so i cant set it there.

ACrowley

29th March 2007, 08:23

LeMoi

29th March 2007, 20:30

When i append AAC tracks, aac-is-sbr is for first track in the GUI (and so it is for every appended track), and yet mmg keeps saying :
Warning: AAC files may contain HE-AAC / AAC+ / SBR AAC audio. This can NOT be detected automatically. Therefore you have to specifiy '--aac-is-sbr 0' manually for this input file if the file actually contains SBR AAC. The file will be muxed in the WRONG way otherwise. Also read mkvmerge's documentation.
Warning: AAC files may contain HE-AAC / AAC+ / SBR AAC audio. This can NOT be detected automatically. Therefore you have to specifiy '--aac-is-sbr 0' manually for this input file if the file actually contains SBR AAC. The file will be muxed in the WRONG way otherwise. Also read mkvmerge's documentation.
Warning: AAC files may contain HE-AAC / AAC+ / SBR AAC audio. This can NOT be detected automatically. Therefore you have to specifiy '--aac-is-sbr 0' manually for this input file if the file actually contains SBR AAC. The file will be muxed in the WRONG way otherwise. Also read mkvmerge's documentation.
Warning: AAC files may contain HE-AAC / AAC+ / SBR AAC audio. This can NOT be detected automatically. Therefore you have to specifiy '--aac-is-sbr 0' manually for this input file if the file actually contains SBR AAC. The file will be muxed in the WRONG way otherwise. Also read mkvmerge's documentation.
Warning: AAC files may contain HE-AAC / AAC+ / SBR AAC audio. This can NOT be detected automatically. Therefore you have to specifiy '--aac-is-sbr 0' manually for this input file if the file actually contains SBR AAC. The file will be muxed in the WRONG way otherwise. Also read mkvmerge's documentation.

woah!

30th March 2007, 01:31

´

create a simple .txt File :

# timecode format v1
assume 23.976

load it in mkvmerge as timecode

when i do that the video seems to be running very fast compared to the audio. heres a screenie of what haali shows :

http://img339.imageshack.us/img339/3973/haali1vk7.jpg

looks like its running at 29.97 to me..

update: ok using this timecode gives me a perfect sync result:

# timecode format v1
assume 29.97
0,126292,23.976

just have to change the amount of frames to match the calc frames given from EVOdemux

# timecode format v1
assume 29.97
0,[FRAME AMOUNT],23.976

NuPogodi

30th March 2007, 12:31

It's probably the right place to ask... Long time ago i compress some video with first vfw-version of h264 (i guess, still compiled by syskin) and mux them into mkv (mkvmerge, versions <1.5.X). Now i need to remux them again, namely, to add new subtitle streams. When i've tried to do it, the current version (2.0) gives me the error -1073741819. I guess it means "no longer support for vfw h264-videostreams", doesnt it? Well, the question is
1. can somebody provide a link for old mkvmerge versions?
2. is there any other way to add subtitles to this video or make it compliant to new mkvmerge versions?
Thanks.

Mosu

30th March 2007, 14:39

Such error numbers are usually crashes in mkvmerge which should normally not happen. Care to upload the file? :)

All older versions of mkvtoolnix are still available at http://www.bunkus.org/videotools/mkvtoolnix/win32/old/

NuPogodi

30th March 2007, 15:42

Such error numbers are usually crashes in mkvmerge which should normally not happen. Care to upload the file? :)
Thanks for a link... you are absolutely right, the older version (1.5) crashes with the same error. Upload? I'm sorry, the whole file was too large (~800MB). So i've splitted the first 1.3MB in TotalCommander (the crash still remains for this file, 20sec) and sent it by e-mail (our server doesnt allow ftp connection) to moritz at bunkus dot org.

echo

3rd April 2007, 01:18

Hi Mosu! I've found myself a bug! When the path contains greek letters and you drag'n'drop a file in mmg I get a "file identification failed" error (Return code: 2) and the path is shown as garbage. If I use the Add button everything works fine...

Oh, it's version 2.0.2 in linux if it matters...

jwa999

5th April 2007, 20:19

Loosing frames when splitting and linking.

When studing the mkv format i found this nice feature: linking split files. So I planned to use it to burn files that are too big. Split them up into ca 1 gig pieces and then archive. But when I split a 11 gig file into 11 pieces and then let the haali splitter glue them all back together, i noticed the result was 10 frames shorter than the original.

I use avisynth/directshowsource to virtualdub to analize the files.

Used mkvmerge 2.0.2 with mmg.exe to split the files
and Haali splitter 1.7.121.0 to view them.

The content of the file is h264 video, ac3 audio and S_TEXT/UTF8 subs.
The original h264 and ac3 audio came from a ts file that was converted to an mkv using haali splitter and muxer in graphedit. I always check that the converted file plays back properly and is in sync.

If i try to glue the split files back together, i'm getting the following error:

Warning: 'E:\!burn\1\e\H264.1080.50i.AC3.5.1-001.mkv' track 2: The current packet's timecode is smaller than that of the previous packet. This usually means that the source file is a Matroska file that has not been created 100% correctly. The timecodes of all packets will be adjusted by 224ms in order not to lose any data. This may throw A/V sync off, but that can be corrected with mkvmerge's "--sync" option. If you already use "--sync" and you still get this warning then do NOT worry -- this is normal. If this error happens more than once and you get this message more than once for a particular track then either is the source file badly mastered, or mkvmerge contains a bug. In this case you should contact the author Moritz Bunkus <moritz@bunkus.org>.

for each of the 11 files.

I'm getting that error as well on other files that i've remuxed with subtitles and then try to mux again. I sometimes add a delay to the audio track to correct sync, I wonder if that has something to do with it.

After the files are appended back together into one file, the 10 frames are still missing.....

On an other sample where it didn't give errors when muxing the video back, the audio gradually goes out of sync.

On a third sample, the linked files play back properly and in sync, but muxing them back together into 1 file gives the same audio errors again and the audio goes terrably out of sync: 192 ms per glued file...

UPDATE: looks like the ac3 track in the original mkv file was not upto spec. after remuxing, extracting and then muxing again, it finally was happy about the ac3 track and no longer gave timecode errors.
Now, after splitting and letting the haali splitter link all the files, it's still missing 10 frames. But when I append all the files back, I get the original number of frames back, except it's one frame shorter than the mkv file that I started out with.
So it looks like the haali splitter is skipping one frame for each mkv file it loads.

UPDATE2: After splitting and then glueing, an analizis of the timecodes reveales that there is a difference: In the original file, the timestamps go up smoothly by every 40ms for video and 32ms for audio. This is also true for the split files. They contain the original timestamps. However, in the glued file, there is now a duplicate timestamp for the video after each glued file, so that every file now starts 40ms earlier and earlier. The audio timestamps "jump" after the second glue point and again after glue points after that to keep up with the video.

CONCLUSION: It looks like the splitting process works ok, but the glue does not maintain the original timestamps and in the process starts making rounding errors.
The Haali splitter must suffer from a similar rounding error and removes a frame around the split point for each file.

jwa.

zeropc

6th April 2007, 02:34

is there any news if or even when v2.0.2 comes out for osx?

philipshu

6th April 2007, 07:56

i tried to use mkvmerge to split a D9 mkv file into two D5s
it says 'die' called: mm_text_io_c::read_next_char(): Invalid UTF-8 char. First byte: 0xfe

i am using 2.0.2 unicode windows version
is there any way to resolve this issue?
thanks

sorry apparently mkvmerge is having some conflict with another program
after shutting down that program the problem is fixed

delacroixp

7th April 2007, 15:23

Use the following switch with mkvmerge, but of course replace <track> with the number for the video track.

--display-dimensions <track>:1024x576
Firstly, thanks again to J_Darnley... the new muxing 'Format specific options' in MkvMerge work like a treat.

http://souls-online.net/delacroixp/AutoMKV/MkvMergeMuxingDisplayThumb.jpg (http://souls-online.net/delacroixp/AutoMKV/MkvMergeMuxingDisplay.jpg)

It all started with 'Band of Brother (http://forum.doom9.org/showpost.php?p=977686&postcount=1684)'... an Q18 CQ-CRF encode that looked lacklustre and bleached compared to the original (see post)...
I have posted an enquiry on H264 Filters (http://forum.doom9.org/showthread.php?t=124430)... but that's a 'complete makeover'... perhaps a small (simple) solution would work best.

I was so impressed with MKV's ability to morph movies after encoding rather than before... that perhaps it's possible to boost colour saturation during the muxing process rather than during the entire encoding process itself.

Are there any colour muxing options available to MKV ?

:):D:eek:
Pascal

zgx

8th April 2007, 13:06

I have a large h264 video file that I got from from and Blu-ray "xport". The file is fine and I can play it back with CoreAVC for example

I want to put it in a MKV container but I am having some problems with it.

MKVmerge accepts the file and everything seams to be fine. But when I play back the resulting MKV file the video is totally distorted.

Anyone have any idea how to mux this file properly?

DreckSoft

9th April 2007, 20:53

Same prob here. Tried m2ts => mkv with GraphEdit, with GDSMux, m2ts => 264 (plays fine) => mkv with MKVToolnix, m2ts => 264 => MP4 (distorted video) => mkv (distorted video). so nothing seems to work :-((

chros

11th April 2007, 11:48

Just a theoretical question: how does the stretch function of an audio stream is working? (it's very useful)

eg: if the value is 1.5, it means that we have 1 and a half times longer duration than the video stream.
So what it does exactly? Does it duplicate frames ? Or miss out some audio samples?

Thanks

Mosu

11th April 2007, 12:35

Just a theoretical question: how does the stretch function of an audio stream is working? (it's very useful)

It only modifies the timecodes, not the samples.

chros

11th April 2007, 23:19

It only modifies the timecodes, not the samples.
Which what is it mean ? Duplicate or drop frames ?
(Sorry if I'm stupid ...)

Mosu

11th April 2007, 23:29

Which what is it mean ? Duplicate or drop frames ?
(Sorry if I'm stupid ...)

It does neither. It only multiplies the timecodes with the factor.

bob0r

13th April 2007, 17:43

@Mosu

I have found some problems with certain .ts H.264 MBAFF files.
Some seek and mux .... some dont seek and dont mux using Haali's gdsmux.exe (lenght is not calculated also)

Now Haali wants a sample file.

As i also had problems with Big H.264 MBAFF files with mkvtoolnix, muxing sometimes stalls at a certain point.

I have this: George.Gently.2007.BBC-HD.1080p.H.264.AC3.2.0.ts 12.2GB Rarred (.001 = rar) on a server.

Now my question is:
Can i upload (FXP ftp to ftp) it to you?

Edit:
Indeed the demuxed video.h264, trying to mux into .mkv gives this again:

mkvmerge v2.0.2 ('You're My Flame') built on Mar 12 2007 16:12:08
'G:\cap\BBC-HD\video.h264': Using the AVC/h.264 ES demultiplexer.
Track 0 of 'G:\cap\BBC-HD\video.h264': Extracted the aspect ratio information from the MPEG-4 layer 10 (AVC) video data and set the display dimensions to 1964/1080.
'G:\cap\BBC-HD\video.h264' track 0: Using the MPEG-4 part 10 ES video output module.
The file 'G:\cap\BBC-HD\video.mkv' has been opened for writing.
'die' called: common.cpp/saferealloc() called from file src/common/common_memory.cpp, line 33: realloc() returned NULL for a size of 198068 bytes.

So it is the perfect sample!

P.S.
can you explain: "set the display dimensions to 1964/1080." Where does the 1964/1080 come from?

chros

13th April 2007, 21:43

It does neither. It only multiplies the timecodes with the factor.
So is it means slowed down audio?

Mosu

16th April 2007, 09:40

bob0r

16th April 2007, 21:09

Haali already is downloading the file, i FXPed him the file.

FXP works............ now pray we get some speed :p

Edit:
[22:18:58] Transferred: george.gently.2007.bbc-hd.1080p.h.264.ac3.2.0.133 72,264,381 bytes in 6 minutes 45 seconds (173.9 KB/s)
ETA: ~ 20 hours.... hope you got 13GB(*2) free :o

Mosu

18th April 2007, 08:42

Damn, I should have read your message sooner. The reason why mkvmerge eats such huge amounts of memory is because it doesn't support MPEG transport streams. It mis-detects your file as a raw AVC elementary stream and tries to parse the file that way. I will add detection of transport streams to mkvmerge so that it'll abort with an appropriate error message and not display this behaviour.

delacroixp

18th April 2007, 11:10

bob0r

18th April 2007, 15:19

@Mosu:

If that was a message to me:
That error occurs with:
George.Gently.2007.BBC-HD.1080p.H.264.AC3.2.0.h264
demuxed with elecard xmuxer pro.

(mplayer is crap when it comes to demuxing)

.h264 or .h264 and .ac3 together, both crash.

But yeah, direct .ts support would be great!

Edit for below:
@DreckSoft
Yup, it seems a pure size/memory issue, but it should be fixed soon now, as Mosu has a 12GB file :)

DreckSoft

18th April 2007, 16:12

bob0r

20th April 2007, 15:41

@Mosu

Haali has managed to "work-around" on the broken H.264 MBAFF .ts file you got also.

So if you can/want to make .ts as import support, you can ask Haali what he did to make it working.

Haali splitter on broken H.264 MBAFF .ts file:
1: allows seeking using mpc
2: allows muxing with gdsmux.exe (so direct .ts to .mkv works now)

Isochroma

22nd April 2007, 19:48

Mosu

23rd April 2007, 07:29

Is it possible to reset the few signalling bytes rather than to remux the entire movie project ?

Not with mkvmerge. mkvmerge is a (re)mux tool, not a property editor.

Mosu

23rd April 2007, 07:31

Some suggested improvements for mkvmerge GUI:

1. Attachments. When an MKV file is added, the tracks are shown and can be checked/unchecked. However, any attached files are not shown in the Attachments box under the Attachments tab.

This should be made to work just like the tracks in the Input tab. All attached files, from all MKV files dropped into the window would be listed in the Attachments box, with check boxes to their left, checked by default.

Yeah, I know... Won't happen due to lack of time.

2. Timecodes. MKV files with timecodes attached to their track(s) don't show up as such, though remuxing the track(s) will preserve the timecodes.

Suggested fix: Timecodes line becomes a drop-down selector box, containing the timecodes (if already existing), and any selected by the Browse... button. Only one in the list can be selected, of course.

You're assuming that the timecode files are somehow stored in a Matroska file, which they aren't. mkvmerge uses the information from a timecode file and calculates the actual timecodes from it. Therefore there's no way to tell from the final Matroska file that a timecode file was used in the first place, much less so what its contents were.

delacroixp

23rd April 2007, 13:34

Not with mkvmerge. mkvmerge is a (re)mux tool, not a property editor.

:thanks: much

I downloaded the MKV Shell Extension and TCMP CDL (http://www.matroska.org/downloads/shellextension/index.html) but I don't know whether that would help... or how...

:):D:eek:
Pascal

.
..
... so maybe a 'property editor' would do the trick... 2 or 3 minutes of remuxing is no big deal but getting-it-right would be kewl...

robU*4

23rd April 2007, 13:46

:thanks: much

I downloaded the MKV Shell Extension and TCMP CDL (http://www.matroska.org/downloads/shellextension/index.html) but I don't know whether that would help... or how...

:):D:eek:
Pascal

.
..
... so maybe a 'property editor' would do the trick... 2 or 3 minutes of remuxing is no big deal but getting-it-right would be kewl...

The Shell Extension would be the tool but it's not 100% compliant and safe. So I think the best way is to remux the file. Is it so much more work ?

Maybe when we have a tag-only app to tag matroska files it could also update safely that kind of information.

delacroixp

23rd April 2007, 17:43

Sometimes I incorrectly set the DAR resolution or aspect ratio and then re-calculate with SeeMoreDigital's Aspect Ratio Signalling (ARS) Calculation Tool (http://forum.doom9.org/showthread.php?t=107039).
Is it possible to reset the few signalling bytes rather than to remux the entire movie project ?

Not with mkvmerge. mkvmerge is a (re)mux tool, not a property editor.
I downloaded the MKV Shell Extension and TCMP CDL (http://www.matroska.org/downloads/shellextension/index.html) but I don't know whether that would help... or how...

The Shell Extension would be the tool but it's not 100% compliant and safe. So I think the best way is to remux the file. Is it so much more work ?

Maybe when we have a tag-only app to tag matroska files it could also update safely that kind of information.

:thanks: much... I hope the Shell Extension works out... I guess more work is better than less.
The tag-only app seams the way to go...

:):D:eek:
Pascal

Isochroma

24th April 2007, 20:42

Today I decided to test remuxing a file without renaming it. The first message I get is:

"The output file 'filename.mkv' already exists. Do you want to overwrite it?"

However, when I click the Yes button, the next error reported is:

"filename.mkv' and of one of the input files is the same. This would cause mkvmerge to overwrite one of your input files. This is most likely not what you want."

It seems redundant that I get two messages, when I could get none at all, if the overwrite method were changed to the following:

1. check if outputfilename == inputfilename (including path) [add case check for case-sensitive filesystems here]

2. if yes, check if silent-overwrite is enabled (new item in preferences). if yes, go to 4, if no continue.

3. ask to overwrite outputfilename. if yes, go to 4

4. overwrite old file with new, by either:

a0.1 check that path+filename of 'filename-old.mkv' is no longer than filesystem maxlength
a0.2 if so, report error & abort, otherwise continue
a1 rename the old file 'filename-old.mkv'
a2 write the new file as 'filename.mkv'
a3 delete 'filename-old.mkv'

or

b0.1 check that path+filename of 'filename-new.mkv' is no longer than filesystem maxlength
b0.2 if so, report error & abort, otherwise continue
b1 write the new file as 'filename-new.mkv'
b2 delete the old file 'filename.mkv'
b3 rename the new file to 'filename.mkv'

It is also possible to modify the binary contents of a file, even changing its length, if the correct OS APIs are called. This would not entail the need for double the space, as the previous method would. However, the previous method is much simpler and should only take a few minutes to implement.

The reason I suggest this improvement, is because I overwrite many mkv files making minor modifications to track names, languages, etc. every day. When this needs to be done, I have to add an extra character to the output filename, mux, delete the original, then rename the new file back, all manually.

This need not be the case; just think how annoying it would be if you had to do this every time you saved a Word document, .txt file, etc.

delacroixp

25th April 2007, 11:04

Today I decided to test remuxing a file without renaming it. The first message I get is:

"The output file 'filename.mkv' already exists. Do you want to overwrite it?"

Solution:
1. check if outputfilename == inputfilename (including path) [add case check for case-sensitive filesystems here]

2. if yes, check if silent-overwrite is enabled (new item in preferences). if yes, go to 4, if no continue.

3. ask to overwrite outputfilename. if yes, go to 4

4. overwrite old file with new, by either:

a0.1 check that path+filename of 'filename-old.mkv' is no longer than filesystem maxlength
a0.2 if so, report error & abort, otherwise continue
a1 rename the old file 'filename-old.mkv'
a2 write the new file as 'filename.mkv'
a3 delete 'filename-old.mkv'

or

b0.1 check that path+filename of 'filename-new.mkv' is no longer than filesystem maxlength
b0.2 if so, report error & abort, otherwise continue
b1 write the new file as 'filename-new.mkv'
b2 delete the old file 'filename.mkv'
b3 rename the new file to 'filename.mkv'

Perhaps, a catch-all solution might be to rename the file 'filename.mux.mkv' right from the start... as implemented in the DivX Mux GUI (http://www.propr.de/divxmuxgui/), leaving the user to rename, relocate or whatever... and possibly renaming 'filename.remux.mkv' as a 2nd refinement in the case of a single file modification.

The idea of creating a temp muxing file and replacing the old one is pretty neat... though a further refinement might be to merely rename the old file 'filename.old.mkv'... leaving the user to delete or otherwise make use of...

Last thought... perhaps we could have an 'Output Folder' in Settings... which would forestall much of the aggravation from counter-intuitive, renaming, relocating and overly-complex interaction...

:):D:eek:
Pascal

Mosu

25th April 2007, 14:15

I can understand the need for such a behaviour, but I don't want to make this overly complicated. Here's what I propose to implement:

A new configuration option is added which controls mmg's output file overwriting. The possible values are "ask before overwriting", "overwrite without asking and resolve file name conflicts" and "rename old file before running mkvmerge".
"ask before overwriting" is the same behaviour as it has always been. It's also the default setting.
"overwrite without asking and resolve file name conflicts" will do the obvious: just overwrite the file if it exists already. If the same name is used for the output file and an input file then the new output file will automatically get a new name in the form "filename.1.mkv"; if that exists, then "filename.2.mkv" etc.
"rename before starting mkvmerge" will cause mmg to rename the existing file to "filename.backup-1.ext", if that one exists, then to "filename.backup-2.ext" etc

I can also add another option for setting a default output folder. At the moment mmg uses the path name of the first file that is added as the output folder.

What I don't like and what I will likely not implement is this:

"always rename the muxed file to something like 'filename.mux.mkv" -- This would probably introduce one unneccessary step for a lot of users: removing the ".mux" in the output file name. If the source files are already named correctly then the destination file should be as close to the same name as possible.

LeMoi

25th April 2007, 14:46

I can understand the need for such a behaviour, but I don't want to make this overly complicated. Here's what I propose to implement:

"rename before starting mkvmerge" will cause mmg to rename the existing file to "filename.backup-1.ext", if that one exists, then to "filename.backup-2.ext" etc
And input filename will be corrected in command line ?

Mosu

25th April 2007, 15:09

And input filename will be corrected in command line ?

No, I'm only talking about renaming output files or changing the name mkvmerge will output to. Input files will never, ever be touched.

bob0r

25th April 2007, 15:17

@Mosu

How is the file going?

LeMoi

25th April 2007, 15:18

""rename before starting mkvmerge" will cause mmg to rename the existing file"

Mosu

25th April 2007, 15:28

How is the file going?

I can mux it with mkvmerge using ~65 MB memory tops. I'll have to clean up the source a bit; expect a new build soon.

Mosu

25th April 2007, 15:30

""rename before starting mkvmerge" will cause mmg to rename the existing file"

...the existing output file.

Like I said, mmg will never rename an input file. Why? Because no user expects that a program would rename a file that the program is supposed to just open for reading. Would you like if MS Word would just rename your files whenever you chose "File -> Save"?

Brother John

25th April 2007, 16:53

I like the idea of those three options. :) Two thoughts about them:

How about a fourth one: "Use file/segment title as file name if present". That's how I name my files and I'd be really surprised if this wasn't a common way to name output files.

Concerning the "rename before" option. A common scenario: You have a video-only file called c:\movie.mkv (probably encoded by x264.exe or xvid_encraw). When you load this file into mmg to mux audio & Co the name for the muxed file is auto-set to c:\movie.mkv. That's a small flaw even in the current mmg version and it'd conflict directly with the "rename before" option: Existing file to be renamed is the input file, but input file renaming is not allowed.

Mosu

25th April 2007, 17:23

How about a fourth one: "Use file/segment title as file name if present". That's how I name my files and I'd be really surprised if this wasn't a common way to name output files.

That would be an additional option and has nothing to do with the other issues :) Maybe. Sounds useful.

Concerning the "rename before" option. A common scenario: You have a video-only file called c:\movie.mkv (probably encoded by x264.exe or xvid_encraw). When you load this file into mmg to mux audio & Co the name for the muxed file is auto-set to c:\movie.mkv.

Oh, you're right. I'll definitely change this so that the automatically created output filename does not equal any of the input filenames.

Isochroma

25th April 2007, 18:12

@Mosu: Interesting ideas... my idea is that it can behave just like Word, etc. in that the user won't have to do any renaming after muxing, if the path\filename is the same for input/output. This would save a lot of work, and be really handy!

However, I just realized that there's a big problem with my original request: what to do if there are errors reported in the muxing process?

Some errors are trivial (ie. no definitive language ID from .ogm source tracks), while other errors may mean problems (xxx bytes of audio discarded... sync may be lost), and others definitely mean a useless output file.

In some of these cases, mkvmerge ought to refrain from purging the original input file, but others it is safe to do so.

So an errorlevel would have to be set in the preferences, above which no input file is purged...

Mosu

25th April 2007, 19:28

Way too much work, Isochroma, sorry.

Isochroma

25th April 2007, 19:36

Yeah, thought so... was just hashing out the complete theoretics for the joy of travelling that road.

Mosu

26th April 2007, 09:40

I'd implement everything you're suggesting instantly if I was actually earning a lot of money with mkvmerge :) It's not that I don't like your ideas, it's just that with my day time job being a programmer most of the time I'm rather unwilling to do more coding in the evening.

Mosu

26th April 2007, 09:43

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.0.2-build20070426-1.rar

Another build for you guys. This one is able to remux the h.264 stream demuxed from George.Gently.2007.BBC-HD.1080p.H.264.AC3.2.0.ts.

Technical explanation: The problem was that the h.264 stream did not contain any IDR slice, and mkvmerge used those for determining when to assign time codes (IDR slice = Matroska key frame). Now mkvmerge also uses type 6 SEI NALUs ( = recovery point indicators) as key frame indicators. On my Linux system mkvmerge is using up to ~65 MB memory if I mux both the h.264 and the AC3 track at the end of the process. This looks promising, but I don't have any other file that big, so testing is up to you :)

madshi

26th April 2007, 10:00

I've a question about h264 support:

When I mux raw h264 files with either mp4box, mp4creator or mkvmerge, I sometimes have the problem that the resulting video file plays slightly shorter or longer than the original file (doesn't matter which of the 3 mentioned tools I use, they behave identical). In such cases the audio track loses sync. I've analyzed the problem and found that in some scenes the mkvmerge muxed video plays like slow motion for a second or so. Then I've tried to mux the Equilibrium HD-DVD h264 stream and it runs too quickly. I guess that the Equilibrium h264 stream doesn't contain "enough" frames and that e.g. static images are realized by using timecodes instead of throwing multiple frames on the same image.

I was able to work around the problem by using Haali's Matroska Splitter + Muxer. Sync is perfect that way.

Is it possible that this new "recovery point indicator" reading could improve the situation? Or is this likely to be just another problem which is still to be solved?

Thanks!

Mosu

26th April 2007, 10:06

In such cases the audio track loses sync. I've analyzed the problem and found that in some scenes the mkvmerge muxed video plays like slow motion for a second or so. Then I've tried to mux the Equilibrium HD-DVD h264 stream and it runs too quickly. I guess that the Equilibrium h264 stream doesn't contain "enough" frames and that e.g. static images are realized by using timecodes instead of throwing multiple frames on the same image.

I was able to work around the problem by using Haali's Matroska Splitter + Muxer. Sync is perfect that way.

Is it possible that this new "recovery point indicator" reading could improve the situation? Or is this likely to be just another problem which is still to be solved?

No, the situation for such cases hasn't improved. As soon as you extract a raw h.264 elementary stream from any container (MPEG TS being a container, too) you lose all timecode information. That's why all three tools behave the same way and show the same problem: They all expect a fixed number of frames per second and create the timecodes accordingly.

What will bring an improvement is when I implement support for MPEG transport streams because then mkvmerge can handle the TS timecodes, too.

madshi

26th April 2007, 12:56

No, the situation for such cases hasn't improved. As soon as you extract a raw h.264 elementary stream from any container (MPEG TS being a container, too) you lose all timecode information. That's why all three tools behave the same way and show the same problem: They all expect a fixed number of frames per second and create the timecodes accordingly.

What will bring an improvement is when I implement support for MPEG transport streams because then mkvmerge can handle the TS timecodes, too.
Ah ok. Thanks!

What about EVO parsing? Are there timecodes in EVOs? If so, does mkvmerge make use of those timecodes? Because when I feed a h264 EVO to mkvmerge, sync is lost, too.

Interestingly, with "TS -> raw h264 -> mkvmerge" usually the video is longer than the audio after muxing. While with "EVO -> mkvmerge" in my case the video was shorter than the audio after muxing. Does that make any sense to you?

delacroixp

26th April 2007, 13:19

What I don't like and what I will likely not implement is this:

"always rename the muxed file to something like 'filename.mux.mkv" -- This would probably introduce one unneccessary step for a lot of users: removing the ".mux" in the output file name. If the source files are already named correctly then the destination file should be as close to the same name as possible.
Agreed

Is it possible to set the "Output filename" to something along the lines of ' c:\*.mkv ' ... where '*' is the original video filename (less the extension).
After that ' c:\MuxedMovies\*.mkv ' and even ' c:\MuxedMovies\*.mux.mkv ' or simply ' *.mux.mkv ' becomes a possibillity... depending on user preference...
I encode a lot of video-only MKV encodes (AutoMKV) and mux in the audio/subtitles manually and even knowing which is the final mux is sometimes usefull.

A default setting is all good.

:):D:eek:
Pascal

*** NOTE ***
I guess this is one of those 3-pillars of tank building problems... firepower vs protection vs mobility ... there is no 'one' solution...
In the case of MkvMerge you choose ... either to rename, relocate or delete... a single path that is satisfactory most of the time...

bob0r

26th April 2007, 13:27

@Mosu

GREAT GREAT GREEEAT WORK!

I demuxed Superstorm.E01.2007.BBC-HD.1080p.H.264.AC3.5.1.ts 8.04GB (even Haali's latest pre gdsmux.exe failed on this)

I demuxed to .h264 and .ac3, muxed 5 minutes then play .mkv to set audio delay in MPC, then muxed the whole thing. Everything went OK!

Now..... i can not wait for .ts support, same as Haali, get ready for Hell! :devil:

Mosu

26th April 2007, 14:10

Ah ok. Thanks!

What about EVO parsing? Are there timecodes in EVOs? If so, does mkvmerge make use of those timecodes? Because when I feed a h264 EVO to mkvmerge, sync is lost, too.

EVOs and VOBs may contain timecodes, but mkvmerge does not use them. VOBs are really cool things, you know... For example there are a lot of files out there in which the timecodes simply reset in the middle of the file.

madshi

26th April 2007, 14:15

EVOs and VOBs contain timecodes, and those are used for the video portion, but not for audio streams.
Hmmmm... Then I think there's probably a bug somewhere in mkvmerge, cause sync is definitely lost with the h264 Equilibrium EVO. I've tried to create the MKV by dropping the EVO into mkvmerge and only muxing the video track. The audio track was demuxed externally. The audio track is in sync, when directly playing the EVO + external audio track through the Haali filters with Media Player Classic. But the sync is lost when throwing the EVO into mkvmerge. I'll upload a h264 test EVO for you.

Mosu

26th April 2007, 14:30

I'll just call it a missing feature that'll be implemented one day. The thing is... Timestamps in EVOs are optional. Meaning that for e.g. the Departed trailer there are 3600 video frames and only 315 MPEG PS packets have a timestamp. I'm not sure how I should re-create the timestamps for the missing frames, nor am I sure how I can actually tell which timecode belongs to which frame, especially with the kind of caching mkvmerge does in order not to slow down too much.

madshi

26th April 2007, 14:41

Yeah, agreed. If you intentionally don't make use of VOB/EVO timecodes (yet), then that's not a bug.

VOB files with resetted timecodes in the middle of the file were probably originally two separate VOB files which were just joined. If you search through the internet about how to join VOB files, some people claim you just need to join the binary files without any further changes. And funnily many splitters seem to cope with such joined VOB files quite well. But it's probably technically incorrect to join VOB files that way.

delacroixp

26th April 2007, 15:29

bob0r

26th April 2007, 23:46

@Mosu

I have some good news!

To my supprise, i captured something of BBC-HD tonight, and everything was changed, they fixed AR signalling (old bbc.ts = mpc saying: 1964 x 1080, new bbc.ts = mpc saying: 1920 x 1080). The bitrate is set a bit lower too (hopefully encoder update to compensate for quality :))

Now, muxing with Haali's gdsmux.exe stalled at 87%, i have had more files doing this, hopefully Haali can fix this.
So i demuxed the .ts to .ac3 and .h264.
Load them into your latest mkvtoolnix, and voila a proper working The.Quatermass.Experiment.2005.BBC-HD.1080p.H.264.AC3.2.0.mkv on my HDD.

Good job!

EDIT:
Haali's next splitter release, will be able to mux the BBC-HD.ts files directly to .mkv also, Haali has fixed 2 issues that prevented muxing.
Now lets hope i can create some more dirty .ts files!! :D

Raw .ts mux directly to .mkv, split with timecodes and boom, result file there, is .mkv actually getting workable??? :o

delacroixp

27th April 2007, 16:54

EDIT:
Haali's next splitter release, will be able to mux the BBC-HD.ts files directly to .mkv also, Haali has fixed 2 issues that prevented muxing.
Now lets hope i can create some more dirty .ts files!! :D

Raw .ts mux directly to .mkv, split with timecodes and boom, result file there, is .mkv actually getting workable??? :o
I'm sure that's just plain evel... we'll have to rename you ' Dr Evil '...

:):D:eek:
Pascal

DreckSoft

28th April 2007, 21:27

Unfortunately the new release is still unable to mux Casino Royale. Still get distorted video.

bob0r

29th April 2007, 16:36

You sure thats not the decoder's fault?
CoreAVC 1.3 does exactly that here... (1.2 works fine)

CruNcher

2nd May 2007, 00:15

@Drecksoft
yeah i expirience the same problems :P http://forum.doom9.org/showthread.php?p=995708#post995708

the best result @ the moment is muxed into .ts/.mpg or.avi but .mp4/.mkv don't work without problems (mp4box,mp4creator,mkvmerge,avimuxgui,gdsmux,Xmuxer Pro) (frame skips, distored slices) it's very strange
CoreAVC 1.3 playbacks H.264 .avi wrong it distores the video too but in another way ( i think that's one of the major bugs Betaboy talked about, because this also happens when connected to Sonics HD Demuxer)

DreckSoft

2nd May 2007, 00:28

You sure thats not the decoder's fault?
CoreAVC 1.3 does exactly that here... (1.2 works fine)

Yup, CoreAVC, MainConcept, ffdShow. Same prob. Original .264 file plays fine, muxed in avi works too (but audio gets out of sync)

KoD

2nd May 2007, 11:49

Well, you get what you are looking for... h264 in avi.

Mosu

2nd May 2007, 12:23

I've had files which show distorted slices because they change the SEI and/or PPS contents in the middle of the stream (which, if I understand the specs correctly, is not allowed). mkvmerge removes all SEIs and PPSes from the bitstream and puts them into the CodecPrivate (which is according to the Matroska specs). I did plan to leave the changing SEIs intact but haven't gotten around to doing that.

Any chance someone could upload one of those files to my FTP server?

DreckSoft

2nd May 2007, 18:33

The entire file would be 25GB and take ages to upload. I could just split it at whatever size you like. It's distorted from the beginning, so a few hundred meg may be enough.

CruNcher

3rd May 2007, 20:27

Mosu i have a small sample 642 MB that gives me headaches, PM me the ftp :)

Mosu

3rd May 2007, 20:43

Cruncher: Read my signature :D

Mosu

3rd May 2007, 20:53

The entire file would be 25GB and take ages to upload. I could just split it at whatever size you like. It's distorted from the beginning, so a few hundred meg may be enough.

Yeah, upload the first 300 MB or so. If it's really completely from the beginning then even 50 MB should be enough.

CruNcher

3rd May 2007, 21:22

oops :D
im allready uploading just take how much you need ;)

Mosu any idea what's wrong ?

Mosu

11th May 2007, 10:27

No, sorry.

Isochroma

12th May 2007, 03:11

DeepBeepMeep

13th May 2007, 00:49

Latest version of Haali filter has many improvements but seems to have lost some compatibility with mkvmerge with matroska file containing VC1. I report this issue here because it seems to be relevant of another issue related to mkmerge:

When trying to merge two mkv with VC1 mkvtoolnix returns this message "'Error: The track number 1 from the file 'D:\Sample.mkv' cannot be appended to the track number 1 from the file 'D:\Sample.mkv' because the track parameters do not match.".

There must certainly something wrong because the error is still there even one tries to merge one file with itself (which should have indentical track parameters!).

The issue can be reproduced with this file: http://www.sendspace.com/file/dvkiyf

To get the error message, the file just need to be appended to itself.

delacroixp

13th May 2007, 10:12

LeMoi

24th May 2007, 13:30

Mosu could you please have a look at this thread (http://forum.doom9.org/showthread.php?p=1006101#post1006101)

Dr.Khron

24th May 2007, 19:16

Is it possible to "attached" hard coded subs to specific audio tracks?

This one DVD I have has four sets of subs: two are full dialog, and the other two are titles only (onscreen text translations for the foriegn language tracks). On the original DVD, you didn't have to select the Titles Only subs, since they became hard subs automatically when you selected one of the foriegn language tracks.

With my current muxing, you have to select the foriegn language track, and then the Titles sub track... would be nice to automate this if I could.

LeMoi

24th May 2007, 19:49

I think you can do it with Haali Media Splitter, in its options, Languages, I think it's "Match subtitle track name to audio".

Neo Fagin

30th May 2007, 04:08

A small feature request (dunno if it's already been requested) - can there be a checkbox in options to enable quiet mode (-q) without error reporting? When muxing DTS created with Surcode, if the DTS has padding, mkvmerge strips the padding which is fine, however it produces thousands of error messages and the process stalls waiting for the console / GUI to catch up to display them, causing it to take literally half a day to mux a DTS track. This also occurs with AC3 and other tracks which have padding in them.

I just add -q to the commandline and do it but I figure a checkbox would be a simple feature to add and would be less confusing.

Mosu

30th May 2007, 08:34

I've been encoding a few seminars from Dr Kent Hovind's 'Creation Science Evangelism' for some christian friends...

The Intro is fine but the main feature needs cropping...
I've encoded both pieces at 640x480 but they have different signalling... the main feature is actually 640x486 DAR.

Matroska does support changing of private codec data in the middle of the stream, but this feature is not widely supported (if at all, Haali's splitter might be the only app supporting this at the moment).

However, Matroska's header fields may NOT change mid stream. Therefore the answer is more likely "no".

Mosu

30th May 2007, 08:38

I found a bug!

When I put a shortcut to MKVMergeGUI into the sendto folder, and right-click an mkv file, select send to > mkvmerge gui, the process starts up but never shows a window, and uses 100% of the cpu.

I figured it would be handy to just send files to it (same as 'open with'), it should work like dropping them on an empty mkvmergegui, right?

xp pro sp2

This is both a bug and a feature request. When you put mmg into the "Send to" folder then it is executed with the filename as its argument. At the moment mmg only supports reading its saved configuration files this way (the ".mmg" extension is mapped to running mmg). That mmg uses 100% CPU is the bug, that you cannot add files this way is the feature request ;)

I've added this to my Bugzilla (https://www.bunkus.org/bugzilla/show_bug.cgi?id=243).

Mosu

30th May 2007, 08:41

There must certainly something wrong because the error is still there even one tries to merge one file with itself (which should have indentical track parameters!).

Definitely a bug. I've downloaded the sample file and opened a bug (https://www.bunkus.org/bugzilla/show_bug.cgi?id=244) for it.

Mosu

30th May 2007, 08:58

A small feature request (dunno if it's already been requested) - can there be a checkbox in options to enable quiet mode (-q) without error reporting?

Hmm, I don't want to add this. If mkvmerge spills out warnings then there are issues the user has to be aware of. Warnings are nothing to laugh at, and suppressing them by default seems like a recipe for grief.

When muxing DTS created with Surcode, if the DTS has padding, mkvmerge strips the padding which is fine, however it produces thousands of error messages and the process stalls waiting for the console / GUI to catch up to display them, causing it to take literally half a day to mux a DTS track. This also occurs with AC3 and other tracks which have padding in them.

I've changed something in the MPEG reader code lately, but I think I haven't built a new Windows build with those changes. Let me do this now. (goes away for a minute) Here you go. Please download this build and test against the files that produce those warnings:
http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.0.2-build20070530-1.rar

Neo Fagin

31st May 2007, 02:39

Hmm, I don't want to add this. If mkvmerge spills out warnings then there are issues the user has to be aware of. Warnings are nothing to laugh at, and suppressing them by default seems like a recipe for grief.Oh, I agree, I just meant an option being available to suppress them. It would logically not be checked by default, obviously. It exists on the commandline so I wasn't sure why it doesn't exist in the GUI.

I'll be trying it on DTS for Pirates of the Caribbean in a bit.

delacroixp

31st May 2007, 09:32

Matroska does support changing of private codec data in the middle of the stream, but this feature is not widely supported (if at all, Haali's splitter might be the only app supporting this at the moment).

However, Matroska's header fields may NOT change mid stream. Therefore the answer is more likely "no".
With critical-mass... menus, stereoscopic3D and various advanced features will undoudtedly take-off.

Thanks for your time...

:):D:eek:
Pascal

Neo Fagin

31st May 2007, 22:42

I've changed something in the MPEG reader code lately, but I think I haven't built a new Windows build with those changes. Let me do this now. (goes away for a minute) Here you go. Please download this build and test against the files that produce those warnings:
http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.0.2-build20070530-1.rarI just tried this on another DTS file made with Surcode and it is still rather slow compared to the commandline with -q, though not "20K per second" slow like it was. It writes about 1MB/sec versus the commandline with -q writing about 4MB/sec.

Mosu

1st June 2007, 07:39

Hmm, so it still does not skip the appropriate amount of byets... I hate MPEG. Could you please upload 10 MB of your file? Thanks.

Neo Fagin

2nd June 2007, 00:12

Hmm, so it still does not skip the appropriate amount of byets... I hate MPEG. Could you please upload 10 MB of your file? Thanks.

D'oh I deleted it, but I'll make another one and up it later today.

delacroixp

4th June 2007, 12:30

D'oh I deleted it, but I'll make another one and up it later today.
What happened to the recycle bin... or do you also shift-delete or possibly even use a shredder...

:):D:eek:
Pascal

bob0r

8th June 2007, 14:54

@Mosu

Any news on fixing Nal-Size on H.264 muxed .mkv files?
The ones with nal size 3 can't be played with the latest cyberlink H.264 decoder.

If no news yet, or not possible soon, can you advice me on how to "fix" the nal-size by remuxing, but keeping the same audio delay? (extra question: How can we see audio delay used in a muxed .mkv file?)

A method used now is:
Demux video from .mkv
Open wrong bad .mkv, select audio only
Then open the H.264 video again and remux with nal-size 4

P.S.
Why is nal-size 3 still selectable?
For H.264 its not valid, but for other video formats it is?

delacroixp

15th June 2007, 12:41

I made 3xH264 encodes of 'Band of Brothers 1'... over-sampled or upscaled to 1440x800, 1280x720 and 1024x576... @ Q23, Q22 and Q19 respectively...
I also made 3xMP4a audio tracks... 5.1 surround @ 48 KHz (full dynamic range), 5.1 surround @ 44.1 KHz (reduced dynamic range) and 2.0 stereo (reduced dynamic range)...
I then muxed the lot, hoping that a friend of mine could do a quality comparison of BoB 1 at each of the 3 encode resolutions on his 40 inch HD LCD TV.

The muxing goes fine but I can't switch video tracks in Zoom Player... the other track is ticked, but not played...
what gives... ???

:):D:eek:
Pascal

KoD

16th June 2007, 08:42

This is very likely not muxing related, but playback related. Your decoder maybe doesn't like switching from 48KHz to 44.1KHz without being resetted or something like that.

delacroixp

16th June 2007, 19:19

This is very likely not muxing related, but playback related. Your decoder maybe doesn't like switching from 48KHz to 44.1KHz without being resetted or something like that.
Actually, the soundtracks change quite happily... it's only the video tracks that have issues...
Also, each video has the same content... so the audio tracks relate equally...

:thanks: for the response...

:):D:eek:
Pascal

foxyshadis

16th June 2007, 23:42

Definitely something I'd ask Blight or Haali first. Switching video seems much less common and less well-tested than audio.

delacroixp

17th June 2007, 13:38

Definitely something I'd ask BeLight or Haali first. Switching video seems much less common and less well-tested than audio.
:thanks: much

:):D:eek:
Pascal

foxyshadis

17th June 2007, 23:40

Blight -> Creator of Zoomplayer
BeLight -> Kurt's besweet GUI.

Not a typo. =p

delacroixp

18th June 2007, 08:28

Blight -> Creator of Zoomplayer
BeLight -> Kurt's besweet GUI.

Not a typo. =p
oops... a little bit of knowledge can be a terrible handicap...

:):D:eek:
Pascal

Btw
sorry for editing your post...

bob0r

21st June 2007, 16:47

@Mosu:

AC3 issue with .mkv (mkvextract(gui))

Delaycut 1.2.1.2: http://www.free-codecs.com/download/AC3_Delay_Corrector.htm

Source file: skyone_ac3_fuckup.ts
mkv file with Haali's gdsmux.exe: skyone_ac3_fuckup.mkv

AC3 file demuxed from .ts with mplayer: skyone_ac3_fuckup_ts_demuxed_mplayer.ac3, info:

====== INPUT FILE INFO ========================
File is ac3
Bitrate (kbit/s) 384
Act rate (kbit/s) 384.000
File size (bytes) 1702880
Channels mode 2/0: L+R
Sampling Frec 48000
Low Frec Effects LFE: Not present
Duration 00:00:35.476
Frame length (ms) 32.000000
Frames/second 31.250000
Num of frames 1108
Bytes per Frame 1536.0000
Size % Framesize 992
CRC present: YES
=============================================
====== TARGET FILE INFO ======================
Start Frame 0
End Frame 1107
Num of Frames 1108
Duration 00:00:35.456
NotFixedDelay 0.0000
=============================================

AC3 file demuxed from .mkv with mkvextractgui: skyone_ac3_fuckup_ts_demuxed_mplayer.ac3.

Or: mkvextract tracks gegdsmuxed.mkv 2:ditisdusfuckedup.ac3
mkvextract -V
mkvextract v2.0.0 ('After The Rain Has Fallen') built on Apr 16 2007 08:48:50

info:

====== INPUT FILE INFO ========================
File is ac3
Bitrate (kbit/s) 64
Act rate (kbit/s) 64.000
File size (bytes) 1653652
Channels mode 2/0: L+R
Sampling Frec 0
Low Frec Effects LFE: Not present
Duration 00:03:26.706
Frame length (ms) 16.000000
Frames/second 62.500000
Num of frames 12919
Bytes per Frame 128.0000
Size % Framesize 20
CRC present: YES
=============================================
====== TARGET FILE INFO ======================
Start Frame 0
End Frame 12918
Num of Frames 12919
Duration 00:03:26.704
NotFixedDelay 0.0000
=============================================

Can you explain this problem?

(all files packed as ac3_issue.7z and uploaded to your FTP)

EDIT:
The source .ts file (ever muxed to .mkv) won't play here at all, only takes 100% cpu, and then i can stop it with alt F4.
Hope Haali can examine the .ts file for us, but it seems the audio file is very fucked :)

Mosu

22nd June 2007, 10:17

@Mosu

Any news on fixing Nal-Size on H.264 muxed .mkv files?
The ones with nal size 3 can't be played with the latest cyberlink H.264 decoder.

I've implemented this in this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.0.2-build20070622-1.rar

Why is nal-size 3 still selectable?
For H.264 its not valid, but for other video formats it is?

Hmm, good question. No, the NALU size only applies to h.264 video, and I can probably take '3' out.

Mosu

22nd June 2007, 10:19

@Mosu:

AC3 issue with .mkv (mkvextract(gui))

...

Source file: skyone_ac3_fuckup.ts
mkv file with Haali's gdsmux.exe: skyone_ac3_fuckup.mkv

mkvextract does NOT modify the AC3 contents during extraction in any way. So my guess is that Haali's gdsmux or, more likely, his TS splitter is at fault. Especially as your also saying:

EDIT:
The source .ts file (ever muxed to .mkv) won't play here at all, only takes 100% cpu, and then i can stop it with alt F4.
Hope Haali can examine the .ts file for us, but it seems the audio file is very fucked :)

I repeat. mkvextract cannot be responsible for the corrupted data. I'd almost guarantee it.

bob0r

22nd June 2007, 14:47

@Mosu:

When i open a .mkv H.264 file in: 2.0.2 - 22 Jun 2007, i still can not change the nal-size in Format specific options.
The option is greyed out.

(Note: all my .mkv are now nal-size 4, i have fixed them manually, so does it detect nal-size 3, or is it a bug?)

Mosu

22nd June 2007, 15:35

Hmm you're right, I haven't updated mmg yet, only mkvmerge. No, mmg does not detect the current NALU size length at all, it just defaults to '3'. I'll change both.

Mosu

23rd June 2007, 10:23

mkvextract does NOT modify the AC3 contents during extraction in any way. So my guess is that Haali's gdsmux or, more likely, his TS splitter is at fault.

I was wrong :) Not completely, but Haali's splitter is not at fault, mkvextract is. Haali uses the 'header removal' compression scheme for AC3 tracks which mkvextract did not support (and not detect either).

Here's a build with support for the reversal of the header removal compression scheme: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.0.2-build20070623-1.rar

bob0r

23rd June 2007, 16:48

Seems to work, File same (duration) of the demuxed .mkv file is shorter, but thats probably due to the delay correct, and thus good.

Something is horribly wrong with this .ts, Haali is looking into it.
But the demuxed audio plays fine......

I was hoping you implemented the nal-size from .mkv option, but i guess i am just impatient :)

Mosu

23rd June 2007, 17:11

I was hoping you implemented the nal-size from .mkv option, but i guess i am just impatient :)

Try http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.0.2-build20070623-3.rar

bob0r

23rd June 2007, 19:40

The option is there, but i cant test it, apparently you cant go back to nal-size 2 :p

Mosu

23rd June 2007, 19:46

What do you mean? That you cannot select it in mmg, or that mkvmerge aborts with an error message about the NALUs being too big for '2'?

bob0r

23rd June 2007, 20:00

Yup

Error: 'I:\beyonce.at.the.bbc.1080i.h.264.mp2.2.0.mkv' track 2: The chosen NALU size length of 2 is too small. Try using '4'.

Ill create some nal-size 3 with some old version, then try make it 4.

Edit: Bad news:

mkvmerge v2.0.2 ('You're My Flame') built on Jun 23 2007 18:05:38
'I:\mpeg2\beyonce.at.the.bbc.1080i.h.264.mp2.2.0_Track2.mkv': Using the Matroska demultiplexer.
'I:\mpeg2\beyonce.at.the.bbc.1080i.h.264.mp2.2.0_Track2.mkv' track 1: Using the MPEG-4 part 10 (AVC) video output module.
'I:\mpeg2\beyonce.at.the.bbc.1080i.h.264.mp2.2.0_Track2.mkv' track 2: Using the passthrough output module for this audio track.
The file 'G:\cap\beyonce.at.the.bbc.1080i.h.264.mp2.2.0_Track2.mkv' has been opened for writing.
'die' called: common.cpp/safememdup() called from file src/common/common_memory.h, line 91: malloc() returned NULL for a size of 242658 bytes.

What i done is:
1: demux beyonce.at.the.bbc.1080i.h.264.mp2.2.0.mkv to .h264 and .mp2
2: remux to .mkv with mkvtoolnix-unicode-2.0.2-build20070622-1.rar, nal-sise 3 (i get this nice warning some decoders may not work)
Tested this remux, and indeed cyberlink fails and coreavc works, so its nal-size 3
3: now i try to re-remux to nal-size3.mkv to a new .mkv with nal-size 4, then i get the above error.

You still should have my BBC-HD H.264 MBAFF sample, so i hope you can reproduce.

Mosu

25th June 2007, 11:56

Yup

Error: 'I:\beyonce.at.the.bbc.1080i.h.264.mp2.2.0.mkv' track 2: The chosen NALU size length of 2 is too small. Try using '4'.

This is of course not a bug, but simply a fact. The source contains NALUs bigger than 65535 bytes; therefore a NALU size length of 2 bytes does not suffice. However...

'die' called: common.cpp/safememdup() called from file src/common/common_memory.h, line 91: malloc() returned NULL for a size of 242658 bytes.

This is a bug, of course. I believe that it was caused by a couple of memory leaks that I've fixed in this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.0.2-build20070625-1.rar

bob0r

25th June 2007, 12:12

Yup, i knew that was not a bug, simply saying i couldn't create a faulty .mkv with a new build.

And also yup, this build fixes that bug and creates a nicely working .mkv file with nal-size 4, you have to change default to 4 bytes though, default = source default, not "specs" default :)

Good work!

Mosu

25th June 2007, 12:49

No, 'default' means '4' for AVC ES tracks (read from AVIs or raw .h264 files) and 'do not change' for non-ES AVC tracks (read from MP4 or Matroska files). The options '2' and '4' request a specific size.

The_Keymaker

28th June 2007, 08:08

Has anyone been able to successfully mux an H.264 encoded file from an HD-DVD into a MKV? I've read through the thread and tried everything I know but to no avail.

The file is a sample from my HD-DVD "Norbit" and is encoded in H.264.

1. I've tried to mux the EVO containing the H.264 stream using GDSmux and MKVtoolnix...NO luck.

2. Using GDSmux and the EVO file, I can re-encode the H.264 stream to VC-1 (@25fps), but when I try to add 23.976 timecodes using MKVtoolnix I get the following Error:

Error: Packet queue not empty for new track ID 1 (flushed: 0). Frames have been lost during remux. This should not have happened. Please contact the author Moritz Bunkus <moritz@bunkus.org> with this error/warning message, a description of what you were trying to do, the command line used and which operating system you are using. Thank you.

Even if this DID work, I'd hate to re-encode, as it takes a Long time and GDSmux craps out after about 65MB of a 17GB file has been "transcoded".

3. I've also tried muxing the raw H.264 stream (obtained from EVOdemux) using MKVtoolnix and GDSmux. MKVtoolnix processes it but the playback is horribly wrong: color flashes and a mostly green screen (sound is OK though).

Any help would be appreciated.

madshi

28th June 2007, 08:19

@The_Keymaker, my Equilibrium h264 EVOs are still sitting on my harddisk waiting to be muxed to MKV. No success so far. Muxing with the Haali filters (or gdsmux) fails. Demuxing and muxing with mkvtoolnix kind of works, but audio sync is lost. Also the h264 "The Departed" EVO trailer cannot be muxed by Haali's filters, either.

I think at this point in time we simply have to wait for a solution. I don't think there is a good one right now. I hope that Haali will fix the problems in a future version of his filters. He is aware of the problem, I think, at least it has been reported to "his" thread here on Doom9.

Mosu

8th July 2007, 15:27

The problem is that I don't have a file for which the 'packet queue' error pops up. I've tried getting my hands on some huge EVOBs but failed so far. So there's nothing I can do at the moment.

The_Keymaker

9th July 2007, 16:17

@mosu,

I don have any huge files to upload, but you can use the following file to help improve MKmerge's ability to MUX h.264 files.

http://www.sendspace.com/file/k15o6r

This particular file CANNOT be successfully muxed by MKmerge.

Regards,
The_Keymaker

Roscoe62

11th July 2007, 10:38

mosu,

Does mkvmerge support muxing a 6 channel LPCM audio track into mkv? If so, what extension do I need to use?

Thank you.

Mosu

13th July 2007, 09:09

Does mkvmerge support muxing a 6 channel LPCM audio track into mkv?

No, it doesn't.

Isochroma

14th July 2007, 01:24

But it should support muxing a 6-channel WAV file into MKV... right? If so, the LPCM could be remuxed into WAV first.

Roscoe62

19th July 2007, 11:02

Yep. Finally figured that one out, tried it and it works beautifully! :)

microchip8

22nd July 2007, 17:06

Hmm I don't have any information about VC1, nor sample files, nor is there a CodecId for it... So... Probably not.

Maybe talk to this guy who's implementing a VC-1 decoder for FFmpeg

http://code.google.com/soc/2006/ffmpeg/appinfo.html?csaid=5AA777DB19E2BB24

honai

30th July 2007, 00:26

madshi

30th July 2007, 07:27

@mosu

I've muxed an EAC3 track into .mkv a while ago. Now that madshi's eac3to has matured I want to extract it again, but MKVExtractGUI says it doesn't support extraction of EAC3. Any idea how to get the raw EAC3 out there?
I think you can use GraphEdit. Connect Haali's Media Splitter with the Dump filter and you're ready to rock!

honai

30th July 2007, 07:54

Yeah, that worked, thanks!

honai

12th August 2007, 19:11

@mosu

Could you please take a look at AVC muxing problems as described in this thread:

http://forum.doom9.org/showthread.php?t=128768

Thanks.

Livesms

12th August 2007, 19:34

How do I cut/trim some part from a mkv video file?

I need to cut 3 sec at the begining of the movie and minute after?
I have no idea how to do it using mmg. Maybe some clm line options???

Mosu

15th August 2007, 20:46

@mosu

I've muxed an EAC3 track into .mkv a while ago. Now that madshi's eac3to has matured I want to extract it again, but MKVExtractGUI says it doesn't support extraction of EAC3. Any idea how to get the raw EAC3 out there?

Use http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.0.2-build20070815-2.rar

DeepBeepMeep

15th August 2007, 22:02

Many thanks Mosu!!!

It seems to work very well with both some AVC coming from an EVO and an m2ts file! Seeking is even fast. There is a small bug though which is not a big deal: the default output name in mkvtoolnix contains two "\" instead of one in the path

Mosu

15th August 2007, 22:29

Oh? Well... that should still work. But I'll take a look at it.

Mosu

19th August 2007, 13:43

Hey,

I've just released mkvtoolnix v2.1.0:

The source code:
http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-2.1.0.tar.bz2

The Windows Unicode binary:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-2.1.0-setup.exe

The other binaries are available from the home page:

http://www.bunkus.org/videotools/mkvtoolnix/

Here's the ChangeLog since the previous release:
------------------------------------------------------------
2007-08-19 Moritz Bunkus <moritz@bunkus.org>

* Released v2.1.0.

2007-08-16 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: Added support for reading MP2 audio tracks from OGM files. Patch by Mihail Zenkov (see AUTHORS).

2007-08-15 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: enhancement: Added support for extracting Dolby Digital Plus (EAC3) tracks.
* mkvmerge: bug fix: SPS and PPS NALUs are no longer removed from AVC/h.264 streams. Hopefully a fix for bug 231.

2007-07-19 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: Fixed SSA/ASS detection for files produced by Aegis Sub which doesn't include a line with '[script info]' in the file.

2007-07-07 Moritz Bunkus <moritz@bunkus.org>
* mmg: enhancement: Added another option how mmg choses the directory if automatic output filename creation is on. Implements all suggestions as listed in bug 248.

2007-07-05 Moritz Bunkus <moritz@bunkus.org>
* mmg: enhancement: Moved the complete 'settings' tab to its own dialog accessible via the 'Settings' option in the 'File' menu.

2007-06-30 Moritz Bunkus <moritz@bunkus.org>
* mmg: new feature: Added a buton 'remove all' which removes all input files and tracks leaving all other options as they are. Fix for bug 248.
* mmg: new feature: Added an option for setting the default output directory if the automatic setting of the output file name is turned on. Fix for bug 248.
* mkvmerge: enhancement: DTS code: Some tools (e.g. Surcode) can create DTS files which are padded with zero bytes after each DTS frame. These zero bytes are now skipped without printing a warning.
* mmg: enhancement: mmg can now be called with any file name as an argument. If it ends with 'mmg' then the file will be loaded as a 'mmg settings file'. Otherwise mmg will 'add' it. Fix for bug 243.

2007-06-27 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The OGM reader uses the OGM's timestamps for video tracks. Before it would just use the current frame number multiplied by the FPS.
* mkvmerge: enhancement: The OGM reader now uses the AVC/h.264 video packetizer for AVC/h.264 tracks so that the aspect ratio can be extracted from it.

2007-06-25 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fixes: Fixed a couple of memory leaks.

2007-06-24 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Added better checks if two tracks can be appended to the passthrough packetizer so that tracks that are otherwise not known to mkvmerge can still be appended (e.g. V_VC1). Fix for bug 244.

2007-06-23 Moritz Bunkus <moritz@bunkus.org>
* mmg: The NALU size length can now be chosen for all AVC tracks, not only for those that are handled by the 'AVC ES packetizer'.
* mkvmerge: bug fix: The 'default track' flag was set to 'yes' for tracks read from Matroska files even if 'no' was specified on the command line.
* mkvextract: new feature: Added support for the 'header removal' encoding scheme.

2007-06-21 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: The NALU size length of an AVC/h.264 track can now be changed even if the source is not an elementary stream (e.g. for MP4 and Matroska files).

2007-06-19 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: Added support for RealAudio v3 in RealMedia files. Patch by Aurelian Jacobs. Fix for bug 246.

2007-06-11 Moritz Bunkus <moritz@bunkus.org>
* mmg: Moved the command line to a separate dialog and reduced the main window's height.

2007-04-30 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Another bug fix for handling various AC3 and E-AC3 files in MPEG program streams.

2007-04-26 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Added support for handling SEI NALUs in AVC/h.264 elementary streams so that "key frames" can be detected even if no IDR slices are present.

2007-04-19 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed the VobSub reader so that "delay:" lines with negative timecodes are accepted. Fix for bug 241.

2007-04-18 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Improved the file type detection code for MPEG transport streams.

2007-03-23 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed a problem reading normal AC3 tracks from MPEG program streams.

2007-03-22 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed an issue with negative/huge timecodes after splitting AVC/h.264 video.

2007-03-16 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: The SRT reader allows "." as the decimal separator as well as ",".

2007-03-12 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed a problem with concatenating more than two subtitle files.

2007-03-08 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: The MPEG program stream reader will now sort the tracks it finds first by their type (video > audio > subs) and then by their stream ID.
* mkvmerge: Disabled the support for DTS tracks in MPEG program streams because DTS HD is not supported yet.
* mkvmerge: enhancement: Implemented a major speed-up for reading MPEG-1/2 and AVC/h.264 tracks from MPEG program streams.

2007-03-05 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: Fixed the MPEG PS reader so that it will just skip blocks whose headers it cannot parse instead of aborting.
* mkvmerge: new feature: Added support for handling AVC/h.264 tracks in MPEG program streams.

2007-03-02 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Added support for EAC3 tracks in MPEG program streams.
* mkvmerge: new feature: Added support for EAC3/DD+ (Dolby Digital Plus) files and tracks (raw EAC3 files or inside Matroska with CodecID A_EAC3).
------------------------------------------------------------

Have fun.

Mosu

buzzqw

19th August 2007, 14:16

:eek: wow!

a huge changelog! with very nice features!

thanks Mosu!

BHH

video_magic

19th August 2007, 15:31

Thank You Mosu! :cool:

Nikos

19th August 2007, 18:38

Many thanks Mosu for your hard work!!!

Isochroma

20th August 2007, 03:03

Your dedicated labours are greatly appreciated. I do however have a question regarding one item in the changelog:

* mkvmerge: Disabled the support for DTS tracks in MPEG program streams because DTS HD is not supported yet.

What about regular DTS tracks in MPEG program streams? In other words, is all DTS-in-MPEG-PS support disabled because there is no DTS-HD capability?

Mosu

20th August 2007, 07:19

What about regular DTS tracks in MPEG program streams? In other words, is all DTS-in-MPEG-PS support disabled because there is no DTS-HD capability?

Yes, because I don't have a method for distinguishing between normal DTS and DTS-HD. The problem is that with DTS-HD mkvmerge spills out thousands of warnings about skipped bytes which are not only annoying but slowing down the muxing process a lot.

I'd really appreciate it if someone could get me two pieces of information: 1. A way to detect if a DTS stream is a DTS-HD stream (not only if it is in another container like MPEG TS) and 2. how to determine the size of each DTS-HD packet. That would probably be everything I need for DTS-HD support. Not that I could actually test it as I lack playback capability ;)

madshi

20th August 2007, 07:58

Maybe this helps?

http://www.digital-digest.com/software/download.php?sid=1551&ssid=0&did=1

It's orbitlee's small dtscore tool which can extract the DTS core from a DTS-HD stream.

Mosu

20th August 2007, 11:49

It's orbitlee's small dtscore tool which can extract the DTS core from a DTS-HD stream.

Unfortunately this doens't help me. orbitlee is using only the information that I have as well. His tool is looking for valid DTS sync words, gets the size "s" of the DTS packet from the headers, copies "s" bytes to the output file, and then it simply looks for the next packet header.

This is what mkvmerge does as well, but it interpretes the presence of stuff between the end of the DTS "core" packet and the next sync word as being garbage (or the stream as being damaged). I don't want to change that behaviour, though, because those error message provide the user with an indication that he should check A/V sync in the case of real damage to the stream. So I would still like to be able to look at the following data and say "oh, this is the HD extension, so let's include it and change the CodecID accordingly".

*sigh* I just love closed standards...

madshi

20th August 2007, 13:05

There are two new DTS formats:

(1) DTS-HD Hi-Resolution Audio
(2) DTS-HD Master Audio

The first one is still lossy, the second one is lossless. As far as I can say, the first one "looks" to us like a normal DTS stream. So there's nothing special we have to do with it.

The 2nd one seems to have additional information in the stream which looks "unknown" to us. As far as I can say (with a hex editor) the two bytes after each valid DTS frame are hex "64 58" (which are the ascii chars "dX"). That might be the signature of DTS-HD Master Audio blocks. The size of these blocks seems to differ, depending on how difficult the audio signal is to compress.

DreckSoft

20th August 2007, 21:57

* mkvmerge: bug fix: SPS and PPS NALUs are no longer removed from AVC/h.264 streams. Hopefully a fix for bug 231.

This helps with distorted video on some files, but there's still a problem with muxing H264.

Con Air Blu-Ray is a example which doesn't work. Remuxing the m2s with TSRemux does work (but I can't add extra Audio here) but demuxing (either the m2ts or the remuxed ts) the H264 and remuxing to MKV results in a async audio (video runs longer than it should).

The same problem exists with all newer Premiere HD Streams. Currently I know no way of properly muxing H264 files extracted from Premiere HD Recordings into MKV. I don't know whats wrong with these files but the problems are the same as with Con Air.

I'm currently running h264_parse on Con Air but is seems as I'll get a HUGE logfile (4MB and growing)

madshi

20th August 2007, 23:19

Currently I know no way of properly muxing H264 files extracted from Premiere HD Recordings into MKV.
"Haali Media Splitter -> Haali Matroska" has never failed on me yet. Well, ok, it fails on HD DVD h264 movies. But it doesn't produce results with sync problems. It either totally fails or totally succeeds. On PremiereHD movies it has always succeeded for me yet. Didn't try very new PremiereHD records yet, though.

Pirks

28th August 2007, 21:30

Mosu, thanks for your great job! But, alas, there's always something to improve :)

Here you go. I've got a list of two suggestions for improvement, let's see if you think they are worth adding to the next release of mkvtoolnix. Everything below is tested with the latest mkvtoolnix 2.1.0

1) Add support for AC3 audio tracks in MOV files. Here's a sample of such a file for you: http://www.dniq-online.com/misc/video/swordfish-explosion.mov

I'm getting the following message when trying to remux that MOV into MKV:

Warning: Quicktime/MP4 reader: Unknown/unsupported FourCC 'ac-3' for track 2.

2) Add support for MIDI soundtrack in MOV files. Here's a sample of such a file for you: http://www.dniq-online.com/misc/screenshots/osx_vs_vista/SwanLake%20and%20MIDI%20soundtrack.mov

mkvtoolnix does not see any MIDI tracks in this file. It says there is only a video track inside.

So what do you think about these two improvements, Mosu? Are they worth looking into? :)

chros

30th September 2007, 17:56

Hi Mosu!

I have post a small guide on this topic with current tools here (http://forum.doom9.org/showthread.php?p=1050021#post1050021), and I have wondered how much work would be to add this feature: I think not much.

The problem with this method:
- we have to write the whole file again (time/space consuming)
- the end point is a Keyframe too

What do you think about this:
- add a frame below the "Splitting frame" on Global tab with the following controls
- add a checkbox labelled "Enable Cutting" (if this checked then the Splitting frame is disabled and vice versa), an another textbox like "...after timecodes" after it labeled "cut at timecodes" AND a checkbox labeled "output 1 file", and a "link files" checkbox
- the new textbox would accept only a pair of timecode values (the cutpoints, so the number of entered timecodes must be mod 2): eg. "00:03:15,00:11:56.569" (in this case we got 1 file) or "00:03:15,00:11:56.569,00:26:00,00:29:45" (in this case there are 2 segments, and we got 1 or 2 files based upon the setting of the checkbox)
- the detection of the begin point of a cut-range is already implemented (if it must be a keyframe/ I frame) and the end point must be an I or P frame (am I right?)
- the only hard work would be with chapters and subtitles WHEN the "output 1 file" is checked (if it's true, you can drop this feature for now :) )

I hope it's really not much work to implement this, so a long awaited feature would be present in mkvmerge !

Thanks

PS:
another feature request with attachments: can you detect them (like embedded fonts), because if I deselect a SSA subtitle stream and I mux the file again, it mux the fonts anyway ...
Or can I delete an attachment file with the command-line of mkvmerge (I saw no examples at the docs) or must I extract the other streams and remux again without it?

Mosu

23rd October 2007, 19:30

Due to missing time I will not implement multiple splitpoints. I might implement better attachment handling for mmg.

Thunderbolt8

23rd October 2007, 21:47

would it be possible to see support for the new HD DVD / blue-ray audio tracks, namely trueHD and dts-hd in the future?

madshi

24th October 2007, 09:14

@Mosu: I know all the dirty details you'd need for DTS-HD High Resolution and DTS-HD Master Audio (how to detect them etc). If you're willing to implement support for that, that'd be great! Please PM me, if you're interested in getting that information from me.

To be honest, I'm not sure if TrueHD and DTS-HD Master Audio are really all that important because we can now reencode them losslessly to FLAC. However, DTS-HD High Resolution support would be quite nice to have.

Thunderbolt8

24th October 2007, 12:16

madshi

24th October 2007, 12:40

from what I heard flac is not compatible to standalone receivers, it can only be used PC related in terms that you can only connect the final output with your speakers, but not to an additional receiver (at least when I understood it correctly). so its good to be able to use the full potential of those tracks currently as flac files. but for the future, when trueHD receivers and alikes become more frequent and cheaper I think for home cinema fans with really good equipment it would be great if they could use their additional non-pc surround hardware then with the original tracks and therefore to be able to mux these tracks into the .mkv
You heard wrong. FLAC is not limited to PC. Most of the media player boxes out there (e.g. Tvix 5100 etc) support FLAC. They can output it over analog output or (decoded to multichannel PCM) over HDMI 1.1. Every receiver that accepts multichannel PCM over HDMI should handle that just fine.

honai

24th October 2007, 15:03

madshi

24th October 2007, 15:14

Yes, but I'm not aware of any PC video/soundcard that transports 5-7 channel PCM (fed from a Windows app) over HDMI, so it's still of limited use. Last news I heard is that manufacturers won't be rolling out this feature in the mid-term because of "licensing" (read: DRM) issues.
HDMI 1.3 bitstream will not come any sooner to HTPC than multichannel PCM. So that's no argument pro TrueHD/DTS-HD. Currently FLAC has an advantage over TrueHD/DTS-HD because it's already supported on HTPC and also by many external media players, while TrueHD/DTS-HD is still difficult to decode perfectly on HTPC and is not supported by *any* external media player yet. I don't really see any argument in favor of TrueHD/DTS-HD MA, unless you want to burn movies to Blu-Ray/HD DVD disc.

honai

24th October 2007, 15:48

Currently FLAC has an advantage over TrueHD/DTS-HD because it's already supported on HTPC

It's only "supported" in a sense that it can be losslessly decoded, but must be *lossy* encoded to AC3 (via ffdshow or AC3Filter) or DTS (on some DTS Connect soundcards) in order to be played back on a receiver - which is what most HD enthusiasts do, anyway. Transport over 5+1 analog cinch cables makes no sense because no matter how clean the copper, you'll lose audio quality.

while TrueHD/DTS-HD is still difficult to decode perfectly on HTPC and is not supported by *any* external media player yet

But TrueHD/DTS-HD is being supported by a growing number of inexpensive external audio receivers, while I didn't hear of any receiver yet that supports FLAC over HDMI.

The point I'm trying to make is that in 1-2 years lots of hardware will do realtime decoding or native transport of TrueHD/DTS-HD, but due to the lack of industry lobbying we won't see that kind of support for FLAC. And as I wrote above, FLAC to PCM over HDMI is going nowhere any time soon because we won't have PC hardware for raw PCM transport from arbitrary sources.

And all TrueHD/DTS-HD -> PCM over HDMI solutions so far only work on a protected audio/video path, so you can't just inject your FLAC -> PCM solution there.

madshi

24th October 2007, 17:38

@honai, can you please tell me a specific scenario in which TrueHD would have advantages over FLAC? I mean what kind of source device are you thinking about (HTPC or external media player box or something else)? What kind of connection (HDMI 1.1 or HDMI 1.3 or something else) and what kind of receiver (decoding capabilities etc)? Just tell me one example. The best one that comes to your mind.

honai

24th October 2007, 23:20

foxyshadis

25th October 2007, 04:59

What is the use of it if you can just losslessly re-encode back to one of these formats if a card or directshow filter supporting them ever does appear? Better to have something that plays right now than something that might play next year.

And since no video card supports multichannel pcm to the receiver right now anyway, it's all a moot point. When the chain is complete, you could translate anything back to TrueHD or Master Audio on the fly the same way we currently can for AC3, although it might use another percentage point or two of cpu.

madshi

25th October 2007, 15:03

I'm not sure I understand the question. But take this scenario:

* PC with software HD-DVD/Blu-ray player
* HDMI video card that does also transport of HD audio over HDMI
* a/v receiver with HDMI that decodes TrueHD (e.g. Pioneer VSX-91)

Bit-perfect transport of audio until the final decoding stage for speaker output.

How would you achieve that with FLAC? You can't, and I don't see it happening in the next few years. Bit-perfect FLAC transport over digital connections to the final decoding stage just isn't possible.
Your example would only work if both video card and receiver have HDMI 1.3. If they have HDMI 1.3 they will also support multichannel PCM transport. So FLAC can be decoded by the PC and sent as multichannel PCM to the receiver. This *is* bit perfect transport over digital connection. It doesn't matter if you transport bitstream or PCM. Audio quality is identical. So in your example FLAC has no disadvantage compared to TrueHD.

honai

25th October 2007, 15:18

If they have HDMI 1.3 they will also support multichannel PCM transport.

No, not in a generic way. So far all announced solutions only work on protected audio and video paths, i.e. bit-perfect transport is only enabled for certified players like PowerDVD and WinDVD which pass the audio stream directly to a DRMed a/v driver. So this will *not* work for FLAC tracks.

So in your example FLAC has no disadvantage compared to TrueHD.

It does because FLAC is not supported by any HD disc standard, and that's the only source that will be transported over HDMI 1.3 by the two major HD disc software player manufacturers.

madshi

25th October 2007, 15:32

No, not in a generic way. So far all announced solutions only work on protected audio and video paths, i.e. bit-perfect transport is only enabled for certified players like PowerDVD and WinDVD which pass the audio stream directly to a DRMed a/v driver. So this will *not* work for FLAC tracks.
I've no idea what you mean. What "announced solutions" are you talking about?

It does because FLAC is not supported by any HD disc standard, and that's the only source that will be transported over HDMI 1.3 by the two major HD disc software player manufacturers.
So you're claiming that PowerDVD and WinDVD will support TrueHD bitstream transport but not multichannel PCM transport? Can you please back this claim up? Because I think you're totally wrong here.

honai

25th October 2007, 15:55

I've no idea what you mean. What "announced solutions" are you talking about?

For example, video cards with nVidia chips that provide HDMI 1.3, i.e. a/v transport over HDMI. These have a protected BIOS (using public/private key cryptography), and only players signed against that BIOS will be able to send HD audio/video over the HDMI connection.

So you're claiming that PowerDVD and WinDVD will support TrueHD bitstream transport but not multichannel PCM transport?

No. I'm saying that PowerDVD and WinDVD can certify to the protected video path that they're secure, and they can honor the DRM flags in the source. So if you're playing a DRMed HD disc with either TrueHD or PCM over HDMI it will work, but it won't for arbitrary PCM streams. PCM over HDMI is not something that is "just there" in the system. You need a specific player software, a specific driver setup, and a specfic video card BIOS (because HD audio over HDMI is routed through the video card) for all of this to work.

madshi

25th October 2007, 15:59

For example, video cards with nVidia chips that provide HDMI 1.3, i.e. a/v transport over HDMI. These have a protected BIOS (using public/private key cryptography), and only players signed against that BIOS will be able to send HD audio/video over the HDMI connection.
Do you have a link? I think you have that backwards. It would be a big step down for any nVidia card user if people couldn't even output unprotected movies over HDMI (and that's what you're claiming). E.g. all the Microsoft VC-1 demos you can download from Microsoft's homepage wouldn't play. No recorded HDTV broadcast would play. That simply cannot be true.

honai

25th October 2007, 16:28

That's not what I intended to express. Let me clarify:

For example, video cards with nVidia chips that provide HDMI 1.3, i.e. a/v transport over HDMI. These have a protected BIOS (using public/private key cryptography), and only players signed against that BIOS will be able to send HD audio/video from HD-DVD/Blu-ray discs over the HDMI connection.

In other words, of course you can send arbitrary video over HDMI (i.e. the DVI part of it), but if I recall correctly the current implementations of HDMI 1.3 on video cards don't provide a system-wide audio driver at all, i.e. you won't be able to send arbitrary audio samples over HDMI at all - unless you run a specific player which directly communicates with the (nVidia) video card protected BIOS, in which case you *can* send TrueHD/PCM over HDMI.

Thunderbolt8

25th October 2007, 17:27

another thing, it would also be great if .evo and . m2ts container as input could be supported!

madshi

25th October 2007, 21:03

For example, video cards with nVidia chips that provide HDMI 1.3, i.e. a/v transport over HDMI. These have a protected BIOS (using public/private key cryptography), and only players signed against that BIOS will be able to send HD audio/video from HD-DVD/Blu-ray discs over the HDMI connection.

In other words, of course you can send arbitrary video over HDMI (i.e. the DVI part of it), but if I recall correctly the current implementations of HDMI 1.3 on video cards don't provide a system-wide audio driver at all, i.e. you won't be able to send arbitrary audio samples over HDMI at all - unless you run a specific player which directly communicates with the (nVidia) video card protected BIOS, in which case you *can* send TrueHD/PCM over HDMI.
You're wrong. The video cards do provide a system-wide audio driver. At least the ATI cards do. And it can be used from MPC.

honai

25th October 2007, 21:41

You're wrong. The video cards do provide a system-wide audio driver.

A system-wide audio driver that acts as a renderer and actually transports multi-channel PCM over HDMI? Do you have documentation for that or screenshots?

madshi

25th October 2007, 21:51

A system-wide audio driver that acts as a renderer and actually transports multi-channel PCM over HDMI? Do you have documentation for that or screenshots?
I didn't say that it transports multichannel PCM over HDMI. Right now it seems that it only supports multichannel AC3 transport or 2 channel PCM transport. But it does seem to be an audio "target" you can speak to from a normal media player. You can check out the ATI 2x00 owners thread on avsforum. They're discussing it there. Search for "PCM" in that thread.

honai

25th October 2007, 21:59

Well, but that's the argument here. 2-channel PCM transport (presumably over SPDIF) is useless for HD audio since the limit is 640kbps/1536kbps. Multi-channel PCM transport over HDMI is the issue, and I stand by my argument: it's only possible by way of special player applications which only support TrueHD/DTS-HD/PCM from HD disc sources, not FLAC or any other DirectShow-bridged format.

madshi

25th October 2007, 22:12

Well, but that's the argument here. 2-channel PCM transport (presumably over SPDIF) is useless for HD audio since the limit is 640kbps/1536kbps. Multi-channel PCM transport over HDMI is the issue
You're missing the point. I never claimed that the ATI card would do multichannel PCM transport. It doesn't. Nor does it do TrueHD nor DTS-HD. Neither from MPC nor from PowerDVD nor from WinDVD. I mentioned the ATI card because you claimed that there'd be no system-wide audio driver for the audio part of a HDMI enabled video card - and you're clearly wrong there.

it's only possible by way of special player applications which only support TrueHD/DTS-HD/PCM from HD disc sources, not FLAC or any other DirectShow-bridged format.
Have you found a link to backup this claim in the meanwhile? I believe you're wrong.

honai

25th October 2007, 22:32

because you claimed that there'd be no system-wide audio driver for the audio part of a HDMI enabled video card

Well, it doesn't take much creativity to interpret my claim correctly: There's no system-wide audio driver for transporting HD audio over HDMI.

Actually, that's what I wrote:

but if I recall correctly the current implementations of HDMI 1.3 on video cards don't provide a system-wide audio driver at all, i.e. you won't be able to send arbitrary audio samples over HDMI at all

Brother John

26th October 2007, 00:48

Humble question, madshi, honai. How is your discussion over the last 10-15 posts relevant to MVKToolnix? Actually I have a hard time figuring that out. And if it was not relevant, wouldn’t it be better to continue this in a separate thread?

madshi

26th October 2007, 08:21

@Brother John, the discussion was about the question whether it's worth adding TrueHD muxing support to mkvtoolnix. But you're right that it got too much OT, so I'll stop discussing now.

Tima

2nd November 2007, 01:52

I have an issue with MMG -- it's not possible to remux an existing mkv (in my case it's avc + ac3) with different frame rate -- the field for fps is grey.

Waiting for a fix if it's possible. :)

foxyshadis

2nd November 2007, 08:14

You have to use a timecode file for that. The only format fps is enabled for is raw h.264 (afaik), and only because mkvmerge isn't capable of reading the real framerate out of it. (Since it can in all other formats, the option is disabled.)

My understanding is that forcing timecodes keeps people from screwing up their sync all the time, but I'm not mosu.

Mosu

2nd November 2007, 08:19

another thing, it would also be great if .evo and . m2ts container as input could be supported!

.evo is accepted, but I think that mmg's "open file" dialog doesn't list it. But drag & drop should work, as should selecting "all files" in the "open file" dialog and then selecting the .evo.

Transport streams (m2ts) are not supported and will probably not be supported in the near future.

Mosu

2nd November 2007, 08:25

I have an issue with MMG -- it's not possible to remux an existing mkv (in my case it's avc + ac3) with different frame rate -- the field for fps is grey.

Waiting for a fix if it's possible. :)

That's not a bug. mkvmerge's "--default-duration" parameter (which is the one that is used for this particular field in mmg) only works with a select number of formats, especially with those that do not contain timecode/FPS information in them. The example foxyshadis has pointed out is the usual case where'd you use this parameter. Raw h264 tracks only contain the frames itself, but neither a timecode for each frame nor a frame rate in general. But for most of the other container/raw formats mkvmerge can actually derive the timecodes from them. Therefore the control is disabled in mkvmerge.

Note that in Matroska you don't simply have a FPS field in a header that you can simply change as you have in an AVI file. In Matroska each frame has its own timecode. Therefore changin the FPS always requires remuxing the whole file.

If you definitely must change all the timecodes then you have to use timecode files, just as foxyshadis has pointed out.

ssjkakaroto

2nd November 2007, 15:51

Hi there Mosu, I'm having a issue with v2.1.0 here:

Whenever I try to convert a OGM file (doesn't matter which) to MKV the file is unplayable, Haali Splitter+MPC report the file having 00:00.

If I convert the files using v2.0.2 (build 20070426) the MKV files work fine.

As I said this happens with any OGM file here but I can upload one to you if needed.

Tima

2nd November 2007, 22:11

Raw h264 tracks only contain the frames itself, but neither a timecode for each frame nor a frame rate in general. But for most of the other container/raw formats mkvmerge can actually derive the timecodes from them. Therefore the control is disabled in mkvmerge.

Note that in Matroska you don't simply have a FPS field in a header that you can simply change as you have in an AVI file. In Matroska each frame has its own timecode. Therefore changin the FPS always requires remuxing the whole file.

I understand, but in my case it's raw AVC track inside mkv, if I understand correctly. So for me there seems no problem to REmux it with another framerate.

KoD

2nd November 2007, 23:09

Tima, use a timecode file. Just go to Start -> All Programs -> MKVtoolnix -> Documentation -> Command Line Reference -> mkvmerge CLI reference and read the chapter on External Timecode Files. You'll see that it's really simple and you don't have to use the CLI either, the GUI can do it too.

In your case, just make a text file, write something like # timecode format v1
assume 23.970
inside it, and then remux your file using that timecode for the video track. How to do it in the mkvmerge GUI should be easy to figure out.

Note:
1. change 23.970 with whatever fps value you want.
2. if your h264 video is vfr though, you can't do anything since you most likely don't know the timestamps for each frame.

Rectal Prolapse

5th November 2007, 07:04

KoD, actually the value should be 23.976. 24/1.001 = 23.976. :)

Thunderbolt8

5th November 2007, 21:58

mosu, is there any chance to have dts-hd (ma & hr) and trueHD support, in .mka or .mkv for example? would be nice to have for all those upcoming hd dvd and blue-ray remuxes ;)

End_of_Eternity

7th November 2007, 03:12

Hi, I am trying to use mkvmerge to split an H264 mkv file into two parts. The first part file is created without any problems, soon after the second file is created mkvmerge crashes.

I am using latest version on Windows Vista, this is the crash info that I get:

Problem Event Name: APPCRASH
Application Name: mkvmerge.exe
Application Version: 0.0.0.0
Application Timestamp: 46c82da7
Fault Module Name: msvcrt.dll
Fault Module Version: 7.0.6000.16386
Fault Module Timestamp: 4549bd61
Exception Code: 40000015
Exception Offset: 00065d45
OS Version: 6.0.6000.2.0.0.768.3
Locale ID: 1033
Additional Information 1: 98bc
Additional Information 2: 744c5eb18e59789eb9c90085a0575d9d
Additional Information 3: 87a2
Additional Information 4: 861d039c8c7d8f1f8ede4cf681494220

I tried splitting using timecodes and the "after duration" function. Both crash at the same point.

The mkv file was created using meGUI with the latest updates. I keep my system pretty clean and I don't have any spyware/crap installed.

Is there any other info I can give you guys to find out the root cause of this crash?

Mosu

7th November 2007, 08:12

Hi there Mosu, I'm having a issue with v2.1.0 here:

Whenever I try to convert a OGM file (doesn't matter which) to MKV the file is unplayable, Haali Splitter+MPC report the file having 00:00.

Yes, please upload a file. The OGM files I have here don't show this behaviour, so I'm not sure what could be wrong (especially as I haven't worked on the OGM reader for quite some time). Maybe uploading the first 50 MB or so should be enouh for me to check it out.

Mosu

7th November 2007, 08:13

mosu, is there any chance to have dts-hd (ma & hr) and trueHD support, in .mka or .mkv for example? would be nice to have for all those upcoming hd dvd and blue-ray remuxes ;)

I've just received some info from madshi regarding DTS-HD, so it should be possible for me. However, I don't do a lot of coding at the moment, so don't hold your breath.

Mosu

7th November 2007, 08:15

Hi, I am trying to use mkvmerge to split an H264 mkv file into two parts. The first part file is created without any problems, soon after the second file is created mkvmerge crashes.

Yeah, I know that there are a couple of problems with mkvmerge's handling of h264 splitting (not only that; the problems are more profound, it's just that h264's frame ordering can be a lot more problematic that other codec's, that's why mkvmerge's simplified assumptions work on most codecs but sometimes not on h264). I don't have an ETA for a fix.

Thunderbolt8

7th November 2007, 12:16

I've just received some info from madshi regarding DTS-HD, so it should be possible for me. However, I don't do a lot of coding at the moment, so don't hold your breath.
well it does not have to be done by the end of the day, but it would be nice to have it before UHD or something like that with new file systems (which would need support too), becomes a new standard :P
thanks!

ssjkakaroto

7th November 2007, 20:39

Yes, please upload a file.Done.

Liisachan

18th November 2007, 07:17

Hi, Mosu, a small thing about mmg 2.1.0 Unicode.
The 'tags' (title info etc) in Ogg (Ogg vorbis in my case) are in UTF8,
still MMG reads it as the current ACP (wrong assumption!) to fill the Track name editbox,
resulting a broken string.
If I type a text directly into the "Track name" editbox of mmg,
mmg is happy to accept a Unicode string.
It is just that it cannot 'extract' it from Ogg.
Plus, it complains:
Warning: The Ogg/OGM file ... contains chapter or title information. Unfortunately the charset used to store this information in the file cannot be identified unambiguously. mkvmerge assumes that your system's current charset is appropriate.

This might be so for OGM, but Ogg has well-defined specs, which say Tags are written in UTF-8.
Besides, if the "Track name" editbox is used, the TITLE from Ogg is ignored, so the above warning is maybe pointless and at least confusing. Well, --chapter-charset UTF-8 does work tho...

IMHO, for texts from Ogg, UTF-8, not the Users ACP, should be assumed. Just a thought. No practical trouble at all :)
Thank you very much!

Liisachan

21st November 2007, 12:48

Another thing. Tags (such as Title) at the end of .wv file are dropped when muxed to MKV/MKA, with the "Warning: wavpack_reader: non-audio block found".

dukey

22nd November 2007, 02:33

could mkvextract write the audio delay in the audio filename ?
That would be useful.

Plus, how can one tell what the audio delay is for an mkv file ?

Isochroma

22nd November 2007, 04:25

I second that motion.

foxyshadis

23rd November 2007, 04:23

could mkvextract write the audio delay in the audio filename ?
That would be useful.

Plus, how can one tell what the audio delay is for an mkv file ?

I don't think mmg creates a soft delay for most audio formats, it'll pad with blank frames instead.

delacroixp

23rd November 2007, 22:15

I don't think mmg creates a soft delay for most audio formats, it'll pad with blank frames instead.
I know nothing about 'mmg and mkv' so it's gr8 to add an interesting thought to the database...

:):devil::D
Pascal

foxyshadis

24th November 2007, 07:48

Really? That's what this whole thread is about, mkvmerge and mmg.

What I meant by the comment is that after you mux, you no longer have any delay at all. You could demux and sync would be maintained. I'm not sure if this is the case for all formats, but definitely is for vorbis.

J_Darnley

24th November 2007, 13:31

foxyshadis is correct. The mkvmerge docs say:
-y, --sync
Synchronize manually, delay the audio track with the id TID by d ms. The track IDs are the same as the ones given with −−identify (see section TRACK IDS).
d > 0: Pad with silent samples.
d < 0: Remove samples from the beginning.
o/p: adjust the timestamps by o/p to fix linear drifts. p defaults to 1000 if omitted. Both o and p can be floating point numbers.
Defaults: no manual sync correction (which is the same as d = 0 and o/p = 1.0).
This option can be used multiple times for an input file applying to several tracks by selecting different track IDs each time.
The silent sample only apply to vorbis tracks for AAC, AC3, DTS and MP3 it will duplicate the first frame. The docs say this list is outdated so Mosu or someone else will need to confirm.

Basically this means that once you use mkvmerge to manually sync an audio track it will be altered to be (approximately) that much longer or shorter so that if you ever need to remux you do not need to specify a delay for that track.

Thunderbolt8

12th December 2007, 20:39

dont know if this has already been mentioned, but mkvmerge sometimes has not only problems with avc files, which were ran through gdsmux before, but also with some broadcasted mpeg2 files.
I remuxed about 6 of those recently and about 3-4 had a little video stutter at some frames in between. this doesnt result in sync issues though, but still looks well, not fluently when this occurs of course. its a small stop of the video 0,25-0.5 seconds, followed by a quick acceleration to have the video back in sync. this wasnt the case with the source .ts file and also not when it was remuxed with gdsmux, only after another mux with mkvmerge afterwards.
when I demux the streams with xport and then just mux them with mkvmerge then everything is fine.

madshi

12th December 2007, 22:03

Thunderbolt8

12th December 2007, 23:34

i have used mkvmerge afterwards, yes, but havent tried that mixing up remuxed video and demuxed sound yet. not sure in how far mkvmerge does rewrite the timestamps automatically though, when I dont specify anything. I cant do that, because then, when I enter 23.976, 29.97 or this number in between which mpeg2repair sometimes reports (for example something like 24.53) the length is always wrong. it only works when I leave this field untouched.

shambles

16th December 2007, 11:58

is there any way to to write the framerate as "24000/1001" and not "23.976" using a timecode file in mmg? i know if you demux the video es you can set it when remuxing but demuxing video when remuxing blu-ray/hd dvd (avc) is inadvisable as far as i've understood

Thunderbolt8

16th December 2007, 17:49

you can use a timecode .txt file and then set the rate for example to 23.9760239, which is already quite close to what you will receive when dividing 24000/1001 with a calculator

madshi

19th December 2007, 09:15

Hmmmmm... Is HD DVD/Blu-Ray mastered in 23.976 or in 24/1.001? I'm not really sure myself. Either way, the difference is really marginal...

shambles

19th December 2007, 17:42

evodemux reports "Frame Rate = 23,976 (24000/1001)" for hd dvds and dgindex/dgavcindex report "Frame Rate: 23.976024 fps" for blu-rays, so i'm pretty sure they're all 24000/1001.. sure the difference is tiny but would still be nice to be able to do it right

madshi

19th December 2007, 18:03

FWIW, for a two hour movie the difference is 7.2ms... :p And as a comparison: One AC3 frame is usually 32ms long. So if you demux audio and video and try to find the correct audio delay and then use delaycut to achieve the final result, you can only move audio forwards/backwards by 32ms at a time. I'm saying this just to put the 7.2ms into the right perspective...

shambles

19th December 2007, 18:13

i know... but i'm a perfectionist when it comes to something i feel passionately about ;)

madshi

19th December 2007, 18:22

Yeah, I see. I like perfect solutions, too.

Thunderbolt8

19th December 2007, 18:35

me too :p
i always mux with 23.9760239 fps. Ive also demuxed some blu-ray files with mencoder (ratatouille) and here the video for example was reported to be 23.976025 fps (which is quite close to 24000/1001 as well).

Liisachan

20th December 2007, 04:03

By confusing 2997/125 and 24000/1001, while the audio delay is just 3.6 ms / hour which is relatively minor, you'll get a lot of subs that are off by one frame. eg. the sub that starts @ 20:51.96 will start at Frame 30018 @ 2997/125, 30017 @ 24000/1001

Nicholi

23rd December 2007, 13:30

Don't forget to use the --timecode-scale parameter. Otherwise it doesn't matter what you write in the timecodes file/etc, everything is rounded to 1ms by default.

delacroixp

23rd December 2007, 19:07

i know... but i'm a perfectionist when it comes to something i feel passionately about ;)
Yeah, I see. I like perfect solutions, too.
me too :p
i always mux with 23.9760239 fps. Ive also demuxed some blu-ray files with mencoder (ratatouille) and here the video for example was reported to be 23.976025 fps (which is quite close to 24000/1001 as well).

Me too... but doesn't perfection include human limitations.

Arn't we looking for perfect 'human' solutions... a cat may see better and demand higher standards and perhaps in a million yrs time humans will have the capacity to appreciate movies with 1000 FPS, 100 megaPixel resolution and 128-bit colour detail.

Surely, mathematical solutions that go beyond human abilities to tell the difference... also fall into the realm of imperfection.

:):devil::D
Pascal

DreckSoft

9th January 2008, 18:30

I see you released new test versions. I tried the one from 02.01.

According to the changelog:
* mkvmerge: bug fix: Rewrote the timecode application
code. Additionally force the "previous cluster timecodes" that
libmatroska uses to the current timecode. This seems to get rid of
libmatroska's assertions about the local timecode being to
small/big to fit into an int16. It also seems to get rid of some
of mkvmerge's errors about the packet queue not being empty.

if should now be possible to rewrite timestamps on mkv files created with GDSMux which previously failed most times.

I tested it on Ratatouille Blu-Ray. Steps:
Merge all movie files into one (copy /b ....)
Remux with TSRemux
Mux to MKV using GDSMux
Add audio stream and rewrite timecode with MKVMerge

Last step failes with:
The file 'D:\Ratatoille.mkv' has been opened for writing.
'die' called: common.cpp/safememdup() called from file src/common/common_memory.h, line 91: malloc() returned NULL for a size of 381332 bytes.

Thunderbolt8

10th January 2008, 01:00

kurt

10th January 2008, 08:53

btw. where to find these test versions?
http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/

DreckSoft

14th January 2008, 08:41

check (if you can playback that file until the error) if the glitches around ~40 mins are still present. if it doesnt work the way you did, then check it with copy /b and then demux the video stream with xport and remux it with mkvmerge (so dont use tsremux and gdsmux) please.

btw. where to find these test versions?

The resulting file has only 6kb so the error is at the very beginning.

Demuxing and remuxing gives async audio. It is sync at the beginning and end (I think) but not in the middle of the movie, so that's not an option.

Lele-brz

14th January 2008, 09:38

Hi,
would it be possible with the upcoming release to force the Cues Section at the beginning of the file?

thanks

bokonon

14th January 2008, 22:32

can someone please help me with an error I've been getting. I'm using MKVMerge GUI v.2.1.0 'Another Place to Fall' and the file plays fine in windows media player

http://i17.tinypic.com/89h7a8m.png

GasKid

19th January 2008, 03:38

Hi,
Don't know whether this has been asked before, since this is such a big thread to go through.
I'm now using mkvmerge GUI to cut a sample from a file, e.g. I want the part from 300s to 400s, when I split with mkvmerge, it returns 3 files, and only the one in the middle is what I want. So I have to delete the other 2 files manually.
Is there any way to prevent generating the other 2 parts what I don't want?
Thanks.

Thunderbolt8

20th January 2008, 00:03

The resulting file has only 6kb so the error is at the very beginning.

Demuxing and remuxing gives async audio. It is sync at the beginning and end (I think) but not in the middle of the movie, so that's not an option.
for me its in sync (or not that much desync that its already noticeable) with xport so long until these glitches occur and then it becomes noticably desync

Brother John

20th January 2008, 00:07

Is there any way to prevent generating the other 2 parts what I don't want?
No. Cutting out single parts is not what the function is designed for.

GasKid

20th January 2008, 06:52

No. Cutting out single parts is not what the function is designed for.

OK thanks.
Then I think I have to find another application to do this for me.

bob0r

20th January 2008, 20:15

@Mosu:

How hard would it be to support .yuv files like these:
ftp://ftp.ldv.e-technik.tu-muenchen.de/pub/test_sequences/1080p/ ?

Quote from #matroska:
shouldn't be hard to add raw support
after all the size of each frame is fixed
all that's needed is the pixel format
the rest is known (width and height)

it would be awesome to add .yuv files to .mkv and simply play them, to compare x264-aq encodes with the original,

joseph5

22nd January 2008, 20:13

OK thanks.
Then I think I have to find another application to do this for me.You can try AviDemux.

delacroixp

23rd January 2008, 04:37

OK thanks.
Then I think I have to find another application to do this for me.
Maybe you can put in a feature request though Mosu is an ardent advocate of the KISS principle (http://www.faqs.org/docs/jargon/K/KISS-Principle.html) and vehemently avoids creeping featurism (http://www.faqs.org/docs/jargon/C/creeping-featurism.html)
which can ultimately destroy an otherwise simple but elegant piece of software.

Perhaps I should add my own feature request for "vertical signalling".
AR signalling works well for full screen but an 800x448 encode signalled with 1.7703 will display at 793x448 (window mode) instead of 800x452 .
Of course, you can avoid the "horizontal shrink phenomenon" by always over encoding the height... eg, 800x464 and all's well !!!

I guess it's more of an MKV spec issue !

:):devil::D
Pascal

Joniii

23rd January 2008, 13:55

Mosu, any chance of VC-1, DTS-HD High Resolution and DTS-HD Master Audio support in the future?

Joniii

23rd January 2008, 21:42

rickardk

24th January 2008, 22:35

Something I just noticed, dunno if it's a bug or what. I demuxed MPEG-4 part 10 ES from Basic Instinct Blu-ray. Demuxed .avc plays fine itself but when I add it into .mkv it takes alot longer for wmp11 to load that .mkv comparing to other backups. When I seek it also takes forever for playback to start again. Also rainbow frames alot. If I mux that .avc into TS, everything works fine.

Same thing with Ratatouille (Blu-ray), Revolver (Blu-ray) and Million Dollar Baby (HD DVD). If remuxed with gdsmux you don't have the rainbow frames but the mkv is unsearchable and will not load in mkvmerge for rewriting timestamps

madshi

24th January 2008, 23:00

Same thing with Ratatouille (Blu-ray), Revolver (Blu-ray) and Million Dollar Baby (HD DVD). If remuxed with gdsmux you don't have the rainbow frames but the mkv is unsearchable and will not load in mkvmerge for rewriting timestamps
Have you tried the latest mkvtoolnix beta build? It has fixed the failing timestamp rewriting for me. See here:

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/

rickardk

24th January 2008, 23:11

Have you tried the latest mkvtoolnix beta build? It has fixed the failing timestamp rewriting for me. See here:

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/

Yes, does not work with Ratatouille or Revolver. Not tried with Million Dollar Baby yet.

Even if I don't rewrite the timestamps the rainbow frames are introduced when just running thoose titles through mkvmerge

allouh

27th January 2008, 03:22

thanks

rickardk

27th January 2008, 10:09

Yes, does not work with Ratatouille or Revolver. Not tried with Million Dollar Baby yet.

Even if I don't rewrite the timestamps the rainbow frames are introduced when just running thoose titles through mkvmerge

Add War [Blu-ray] to that list...

tjf

27th January 2008, 13:14

Something I just noticed, dunno if it's a bug or what. I demuxed MPEG-4 part 10 ES from Basic Instinct Blu-ray. Demuxed .avc plays fine itself but when I add it into .mkv it takes alot longer for wmp11 to load that .mkv comparing to other backups. When I seek it also takes forever for playback to start again. Also rainbow frames alot. If I mux that .avc into TS, everything works fine.

Same problem with Harsh Times. Demuxed mkv (created with ea3to) file plays fine, but once I add audio (FLAC), subtitles and chapters, it takes forever to open. I used Jan 15 beta of MKVMergeGUI. I have uploaded a sample here:

http://rapidshare.com/files/86999542/Harsh_Times-001.mkv.html

Joniii

27th January 2008, 19:41

I muxed that h264 stream into avi with dts and I got no problems then. So maybe temporary solution to make these problematic titles work with mkv would be to first mux h264 into avi with AVC2AVI Mod (like VC1CONV with VC-1 does).

Unearthly

3rd February 2008, 03:26

Right now MKVMerge can use video from a 'Fake AVI' made by makeavis, but not audio. Would it be possible to add the ability to mux this audio into an mkv as well?

Isochroma

17th February 2008, 20:30

I've been merging some AVC MP4 files. It complains about the CTTS atom being missing, and that I should check the resulting file to make sure playback is ok.

This warning is useful, but since I attach a timecodes file to the video track, it's not necessary. So could the warning be suppressed when a timecodes file is attached to the video track?

zeropc

21st February 2008, 05:49

i guess mkvtoolnix for mac os x has been terminated :(

for months we haven't seen a new release.

Mosu

5th March 2008, 17:34

Hello users and package maintainers,

I've released a new version of MKVToolNix, v2.2.0. It contains major bug fixes (a lot of crashes with should be gone) and a couple of new features.

Here are the usual links to the most interesting downloads:

The source code:
http://www.bunkus.org/videotools/mkvtoolnix/sources/ mkvtoolnix-2.2.0.tar.bz2

The binaries for Windows 2000, XP or newer:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-2.2.0-setup.exe

The program home page:
http://www.bunkus.org/videotools/mkvtoolnix/index.html

Binaries for a couple of Linux distributions are available from the home page. The users of Debian and Ubuntu that use my Apt repositories should note that I've renamed my package to match the official package names in Debian and Ubuntu. You can get this release of MKVToolNix with "apt-get install mkvtoolnix mkvtoolnix-gui".

As always I'll finish with the ChangeLog between the previous release 2.1.0 and this release.

Have fun :)

Regards,
Mosu

-----------------------------------------
2008-03-04 Moritz Bunkus <moritz@bunkus.org>
* Released v2.2.0.

2008-02-29 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Added support for handling AC3 in WAV in ACM mode.

2008-02-28 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Added support for reading AC3 from QuickTime/MP4 files. Fix for bug 254.

2008-02-27 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Added support for handling AC3 in WAV in IEC 61937 compatible streams (aka SPDIF mode).
* mkvmerge: new feature: Added support for WAV files with multiple data chunks.
* mkvmerge: bug fix: Fixed a cause for the error message "no data chunk found" by fixing the skipping of 'fmt ' chunks.

2008-02-23 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Added support for AAC-in-AVI with CodecID 0x706d as created by mencoder. Fix for bug 266.

2008-02-20 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Rewrote the OGM reader code. Another part of a fix for bug 267.

2007-12-31 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Rewrote the timecode application code. Additionally force the "previous cluster timecodes" that libmatroska uses to the current timecode. This seems to get rid of libmatroska's assertions about the local timecode being to small/big to fit into an int16. It also seems to get rid of some of mkvmerge's errors about the packet queue not being empty, and it fixes a couple of crashes with file splitting.

2007-12-22 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: OGM files with non-Theora video tracks caused mkvmerge to fail since 2.1.0, or the resulting file was unplayable. Fix for bug 267.

2007-10-11 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Accept other Theora header versions than 3.2.0 as long as the major version is 3 and the minor 2. Fix for bug 262.

2007-09-02 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: MPEG PS reader: Fixed the resyncing mechanism during normal reads. Another fix for bug 259.
* mkvmerge: bug fix: MPEG PS reader: mkvmerge tries to resync to the next MPEG start code in case of error during stream detection. Fix for bug 259.

2007-08-31 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: SVQ1 video tracks read from QuickTime files are output as V_MS/VFW/FOURCC tracks and not as V_QUICKTIME tracks. Fix for bug 257.

2007-08-30 Moritz Bunkus <moritz@bunkus.org>
* avilib: bug fix: Fixed a segmentation fault if reading the first part of an index failed but a second/other index part is present. Fix for bug 256.

2007-08-19 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: SRT files that contain coordinates in the timecode line are supported. The coordinates are discarded automatically (as S_TEXT/SRT doesn't support them), and a warning is shown.
-----------------------------------------

madshi

5th March 2008, 17:40

Thank you... :)

Liisachan

5th March 2008, 21:41

Thank you very much!

microchip8

5th March 2008, 22:07

Great work!!! Many thanks :)

Mosu

10th March 2008, 14:13

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.2.0-build20080310-1.rar

2008-03-09 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Added support for skipping ID3 tags in AAC and AC3 files. Fix for bug 204.
* mkvmerge: new feature: Added support for DTS-HD (both "master audio" and "high resolution").

Maybe some of you would like to test DTS-HD support. I'd appreciate it.

delacroixp

10th March 2008, 14:59

Hello users and package maintainers,

I've released a new version of MKVToolNix, v2.2.0. It contains major bug fixes (a lot of crashes which should be gone) and a couple of new features.

:thanks: much !!!

:):devil::D
Pascal

ps
Any news about menu tools for MKV ???

nautilus7

10th March 2008, 15:44

Thanks very much for DTS-HD support!

EDIT: What is the extension to use for dts-hd files? When i open a dts-hd file (using .dtshd extension) it is shown as dts only. Is this ok?

menlvd

10th March 2008, 22:52

waiting update haali spliter for support DTS-HD :)

Mosu

10th March 2008, 23:08

At the moment mkvmerge uses the normal A_DTS codec ID for DTS-HD. So I can already play such files on Windows, but I'd guess that the non-core part is dropped before decoding... But I don't know enough about the usual Windows decoders/filters to be sure (it's Haali -> ffdshow for me).

menlvd

10th March 2008, 23:44

nautilus7

11th March 2008, 01:05

So, does this mean that ID will be changed to DTS-HD when haali is updated?

I muxed a dts-hd master audio track and haali reported variable bitrate for the track (diagram). Is there a chance that the hd extensions are passed to the decoder from haali?

How do i set sonic audio decoder to be used and not the mpc-hc's internal decoder? I know, it's not the proper section to ask...

madshi

11th March 2008, 09:50

IMO it's correct to mux the DTS-HD track under the DTS codec ID cause all DTS-HD "capable" decoders expect this codec ID for DTS-HD streams, too. DTS-HD "capable" decoders are Nero and Sonic. Nero understands DTS-HD and shows the correct name (e.g. "DTS-HD Master Audio") but then only decodes the core. Sonic decodes the full DTS-HD information.

Haali's Media Splitter intentionally only outputs the DTS core when splitting EVO and m2ts files. But I'm not sure what Haali's splitter does with MKV files. I think there's a chance that Haali will not cut the DTS-HD packets away when an MKV is properly muxed with the DTS-HD packets in it. But I've not had a chance to test that yet. You can test it yourself by doing this in graphedit:

MKV -> Haali Media Splitter -> Nero Audio Decoder 2

Note that the MKV must be muxed with the latest mkvtoolnix version and the Nero Audio Decoder must be from Nero 7 (Nero 8 won't work) and graphedit.exe must be renamed to recode.exe.

You can then in graphedit check (Nero Decoder properties) whether Nero reports "DTS-HD Master Audio" or "DTS-HD High Resolution". If it does, then Haali doesn't throw the DTS-HD packets away from MKV files.

P.S: Of course you could also simply do "MKV -> Haali Media Splitter -> Dump" and compare the file size of the dumped DTS-HD track to the original demuxed one.

menlvd

11th March 2008, 16:42

madshi

luck with mkv/mka container :)
not luck with ts/m2ts container :(
we want that ts/m2ts container support too by haali splitter, any chance?

madshi

11th March 2008, 19:30

we want that ts/m2ts container support too by haali splitter, any chance?
You're asking this question in the wrong thread and to the wrong people. I don't think Haali is subscribed to this thread.

nautilus7

12th March 2008, 00:47

Confirmed... Haali spits out all dts-hd info from a mkv.

Selur

12th March 2008, 17:34

little request:

Would be nice if one could specify the 'assume framerate' for a video track via command line without the need to create a timecode file first.

Cu Selur

Atak_Snajpera

12th March 2008, 18:02

use this
--default-duration 0:xxfps

Selur

13th March 2008, 13:25

thanks :)

Isochroma

13th March 2008, 23:41

Suggested features for new builds:

1. Auto-set added tracks to selected language, if they have no language to begin with.

2. When warnings popup, please oh please make the dialogue have focus so I can just hit Enter rather than having to click to select the window first.

3. When adding both a video and audio track in one drag-and-drop operation, the app sets output type to MKS; why?

4. Option: set default framerate to user-defined value on tracks that would otherwise require it, rather than it always being auto-set to 25.

~bT~

14th March 2008, 13:40

this might be a stupid question considering that I have been using this tool for a long while now.

does it save to .mp4?

buzzqw

15th March 2008, 09:11

does it save to .mp4?

no... it's MKVtoolnix ;)

BHH

~bT~

15th March 2008, 12:46

^ thanks. i thought so. its just someone was telling me otherwise.

buzzqw

15th March 2008, 13:16

@~bT~
you can use YAMB, not full featured as mkvtoolnix but quite friendly

BHH

stax76

16th March 2008, 22:34

The docs use unicode minus (&minus == 0x2212) and the cmdl parser don't understand it. You can't copy/paste a switch from browser to shell and the browser search fails.

Mosu

17th March 2008, 15:49

The docs use unicode minus (&minus == 0x2212) and the cmdl parser don't understand it. You can't copy/paste a switch from browser to shell and the browser search fails.

True. Wasn't my decision, though... groff does it by itself (for those who don't know what groff is: it's a program for turning Unix manual pages into other data, e.g. HTML).

I've fixed the HTML docs by replacing − with a normal "-" instead:

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.2.0-build20080317-1.rar

No other changes in this build.

stax76

17th March 2008, 16:14

Thanks for fixing it mosu, I'll update StaxRip (http://forum.doom9.org/showthread.php?t=102652&page=86)to use this build (I host all apps myself now).

stax76

22nd March 2008, 06:29

it would be handy if mkvextract would demux everything in case the only argument is a mkv file.

plugh

3rd April 2008, 00:27

mkv noob here...

I was experimenting with mkvmerge and mkvextract gui's and have a couple questions.

1) When I mux Xvid (from avi file) into mkv, I can optionally choose a "FourCC". It seems as though whether I leave the option alone (blank) or explicitly choose 'XVID', mkvextractgui reports the resulting stream in the mkv file as "(V_MS/VFW/FOURCC,XVID)".

The little bit of reading I've done about mkv 'codec ids' would lead me to believe that this is what is referred to as 'avi compatibility mode'. I am ALSO under the impression that there is a NON-'avi compatible' way / format / id / ??? to include 'MPEG4-ASP' video (such as, for example, Xvid) into the file.

How?

2) When I originally muxed my audio and video into the mkv, I specified the audio delay. When I extract the streams back out to files, I can't seem to find the original delay value anywhere (which I would need for a later re-mux).

Is it lost in the process?

Thanks!

chros

4th April 2008, 09:03

2) When I originally muxed my audio and video into the mkv, I specified the audio delay. When I extract the streams back out to files, I can't seem to find the original delay value anywhere (which I would need for a later re-mux).

Is it lost in the process?
No, it's zeropadded or cutted when you mux it. So, when you demux it it's still in sync ...
Try it with a small sample ...

stax76

4th April 2008, 09:11

In case anybody is interested, StaxRip demuxes now all streams from mkv using mkvextract: http://forum.doom9.org/showthread.php?p=1121319#post1121319

Brother John

4th April 2008, 22:56

I am ALSO under the impression that there is a NON-'avi compatible' way / format / id / ??? to include 'MPEG4-ASP' video (such as, for example, Xvid) into the file.
Use Xvid_Encraw and don't output to AVI. This will produce a "native" MPEG-4 stream with a codec ID of iirc MPEG4/ISO/ASP.

Eragon4ever

4th April 2008, 23:27

The little bit of reading I've done about mkv 'codec ids' would lead me to believe that this is what is referred to as 'avi compatibility mode'. I am ALSO under the impression that there is a NON-'avi compatible' way / format / id / ??? to include 'MPEG4-ASP' video (such as, for example, Xvid) into the file.

How?

There is the --engage native_mpeg4 switch but I wouldn't recommend to use it. Last time I tested it the resulting files weren't playing correctly.

plugh

5th April 2008, 06:14

Thanks for the answers.
encraw isn't an option at the moment.
Is there a way to, uh, invoke the --engage via mmg?

fyi - I sort of found a way; avidemux will read avi and write mkv, with the xvid tagged as mpeg4/iso/asp. Unfortunately, I ran into a 'large file' issue with that approach.

For now I'm just leaving it as vfw/fourcc, as both xbox/xbmc and AppleTV/Perrian seem willing to accept the file this way.

Eragon4ever

5th April 2008, 16:06

Is there a way to, uh, invoke the --engage via mmg?
Muxing -> Add command line options
But you have been warned...

plugh

5th April 2008, 16:11

Muxing -> Add command line options
But you have been warned...

Acknowledged. And thanks...

(Oh no! the 'Laughing Man'! :eek: run away run away)

plugh

5th April 2008, 18:25

OK New question... I have processed a transport stream capture. I have video (xvid), audio (aac) and subs (srt).

The subs were created by extracting the closed caption data from the stream with 'ccextractor'. This utility will produce text lines in the srt file with leading blanks, in order to simulate the Closed Caption screen positioning.

I mux'd the srt into an mkv with mmg, but the horizontal positioning was not present on playback. I extracted them back out with mkvextractGUI, and sure enough, the leading blanks were gone. I'm guessing mkvmerge stripped them.

Is there a way to preserve the leading spaces?

Mosu

14th April 2008, 22:42

Is there a way to preserve the leading spaces?

The only way is to use this bugfixed version: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.2.0-build20080414-1.rar

delacroixp

19th April 2008, 08:32

Is there a way to preserve the leading spaces?
The only way is to use this bugfixed version: mkvtoolnix-unicode-2.2.0-build20080414-1 (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.2.0-build20080414-1.rar)
Nice one.

:):devil::D
Pascal

plugh

23rd April 2008, 04:22

I'll give it a whirl.

Thanks!

Tima

4th May 2008, 14:33

I have a AVC + AAC + AAC Matroska file, which has been muxed by mkvmerge 1.0.2. The opening and especially seeking in player were extremely slow, so I decided to remux it with new mkvmerge. I tried versions 2.2.0-release, 2.2.0-latest_alpha and 1.4.0 -- all they fail to remux the file with following error:

Error: 'E:\The_Story_of_O.mkv' track 1: Could not extract the decoder specific config data (AVCC) from this AVC/h.264 track.

NanoBot

13th May 2008, 22:48

Hi there,

I think I found a bug in the h.264 import module of mkvtoolnix, but I am not sure about that. So I will describe the symptoms and perhabs somebody more familiar with h.264 streams and mkvtoolnix might be able to tell if it really is a bug:

Some time ago I recorded some DVB transport streams containing one h.264 video stream and one AC3 audio stream from a german tv station. I want to include additional audio streams, subtitle streams and chapter information ( ripped from SD DVDs of the same titles I own ). So I demultiplexed the ts to es using either "xport.exe" or "tsMuxeRGUI", and remultiplexed them to mkv using the latest version of mkvMerge GUI.

But with one of those recordings ( it is Episode6 in 1080i50 ) I ran into problems concerning the play length of the movie. The original ts plays fine with mpc and shows a playtime of 193813 video frames which equals 02:09:12.480 at 25fps. But after remultiplexing it to mkv, the playtime is shown as 2:09:30, which of course should not happen.

When I am using graphedit with haalis simple media splitter and haalis matroska muxxer, the resulting mkv file has the correct playtime, but when trying to navigate within the new file, mpc freezes. If I am remultiplexing the elementary streams to a transport stream using tsmuxeRGUI, the new ts also has a correct playtime of 2:09:12

In my attempt to find out the reason to this behavior, I analyzed the ts and the h.264 es with the trial version of elecards streamEye and found, that the encoding format is changing from frame based to field based at the beginning of a GOP at a playtime of 0:00:32:480 and goes back to frame based within a GOP at a playtime of 0:00:37:680. There may be more of those changes within the stream, but until now I did not search for more occurrences. Unfortunately I am not able to tell if they use PAFF oder MBAFF encoding since I do not know where to look in the h.264 header for this information.

Now back to mkvmergeGUI: What I suspect is, that mkvmerge accidentally counts the fields as frames and therefore produces a mkv file with a too long playtime.

If it would be helpful I am able to supply a small piece of the transport stream or the elementary stream containing such a "change" situation. But before doing that I would like to ask if this would comply to the rules of the forum, since it would be a ( rather small ) part of copyrighted material.

C.U. NanoBot

hubereevez

27th June 2008, 14:56

mkvmerge crash when adding an ogm file (see jpg)

Worked with 2.1.0 but without the chapters

Here is my ogm file :

Général
Complete name : H:\test.ogm
Format : OGG
File size : 702 Mio
Duration : 2h 42mn
Overal bit rate : 603 Kbps
Movie name : Me
Performer : Me

Vidéo
Format : MPEG-4 Visual
Codec ID : DX50
Codec ID/Hint : DivX 5
Width : 496 pixels
Height : 208 pixels
Display aspect ratio : 2.35
Frame rate : 25.000 Im/s

Audio
Format : Vorbis
Format settings, Floor : 1
Duration : 2h 42mn
Channel(s) : 2 canaux
Sampling rate : 48.0 KHz
Language : english

Texte
Language : french

Chapitres
01 : 00:00:00.000 Chapter 1
02 : 00:07:51.840 Chapter 2
...

Thanks

delacroixp

27th June 2008, 18:49

I'm pleased to hear that DivX 7 will be supporting the MKV container:

DigitAl56K - DARC (DivX Advanced Research Team) (http://forum.doom9.org/showthread.php?p=1152183#post1152183) : DivX 7 will use the MKV container format ! That's right, you heard it here first: our new format does not use AVI !

It's all good !

:):devil::D
Pascal

ps
I know that nothing is a done deal untill the fat lady sings but hopefully MKV will acquire that extra mile to sort the menu system.

Mosu

28th June 2008, 11:28

mkvmerge crash when adding an ogm file (see jpg)

Try http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.2.0-build20080515-1.rar

hubereevez

28th June 2008, 13:57

Works now ! Thks Mosu :)

GasKid

23rd July 2008, 06:10

Hi,

I have an mkv file I muxed with mkvmerge earlier, but I forget the audio delay I set. I googled and found this thread (http://forum.doom9.org/showthread.php?t=111746). It tells me to "try mkvinfo -v and see when the timecode of the first audio packet".

I did so, and got something like this:
| + Block (track number 2, 8 frame(s), timecode 0.038s = 00:00:00.038000000)
But I remember that I set a negative value.

Then I did some tests, and found out that when setting a positive delay in mkvmerge, everything is OK, but when the value is negative, mkvinfo will report a positive timecode.

Haven't checked how's the output files like yet, so I don't know whether it's mkvmerge's problem or mkvinfo's, or just my problem. I'll check them asap.

Can someone please help me? Thanks.

btw, I'm using mkvtoolnix 2.2.0, the audio is in aac format.

====
Sorry for the late update.
I checked the file, the audio is properly adjusted. So it appears to be mkvinfo's problem?
I was using --delay to adjust audio delay.

madshi

22nd August 2008, 14:59

@Mosu,

all the MKV muxers remove the AUDs (00 00 01 09 xx) when muxing h264 streams to MKV. That's alright, of course. But that means if we mux a raw h264 stream to MKV and then demux it again, we lose bit perfectness. Which is quite ugly.

So here comes my feature wish: Could you please readd AUDs into the stream when demuxing h264 streams with mkvextract? I think/hope it shouldn't be difficult to do.

Thank you... :)

Mosu

22nd August 2008, 15:16

Do you have a small sample file with such elements? I don't seem to have any, so testing might be a bit difficult.

Mosu

22nd August 2008, 15:18

I have an mkv file I muxed with mkvmerge earlier, but I forget the audio delay I set. I googled and found this thread (http://forum.doom9.org/showthread.php?t=111746). It tells me to "try mkvinfo -v and see when the timecode of the first audio packet".

I did so, and got something like this:
| + Block (track number 2, 8 frame(s), timecode 0.038s = 00:00:00.038000000)
But I remember that I set a negative value.

Then I did some tests, and found out that when setting a positive delay in mkvmerge, everything is OK, but when the value is negative, mkvinfo will report a positive timecode.

When you delay a track then the delay is added to all timecodes. If your delay is negative then some packets may end up with negative timecodes. These packets are dropped and not written to the output file (!). Therefore you should never see packets with negative timecodes in mkvinfo's output.

There's no way to retrieve the delay used during muxing reliably.

madshi

22nd August 2008, 15:26

Do you have a small sample file with such elements? I don't seem to have any, so testing might be a bit difficult.
Don't you have any HD DVD and Blu-Ray h264 samples? I believe most of them (or all?) have AUDs. But I'll upload a few samples...

sehgal.v7

22nd August 2008, 16:10

@Mosu
Reference to above question
hxxp://rapidshare.com/files/139273329/Original.h264

Original Raw Stream size - 10,485,888
Muxed with mkvMerge size - 8,478,255
Extracted raw stream with mkvExtract - 8,469,695

Original Stream to TS container (TSMuxer) > TS to MKV (eac3to) - 10,485,888 > 10,775,784 > 8,473,127

madshi

22nd August 2008, 16:23

Here are 2 trailers with AUDs, one from a HD DVD, one from a Blu-Ray:

http://madshi.net/h264.evo
http://madshi.net/h264.m2ts

Thanks for looking into this... :)

P.S: Here's another thing (not as important, though): Some MKVs have the sequence headers stored in both the "codec private" data and in the frame data itself, too. Now as a result when demuxing a h264 stream with mkvextract, the sequence headers are stored twice in the beginning of the h264 stream. It would be great if mkvextract could check if the codec private data is identical to the beginning of the first frame. In that case the codec private data should not be prepended when demuxing the h264 stream.

P.P.S: The Blu-Ray trailer is still uploading. Should be ready for download in about 1 hour.

Mosu

22nd August 2008, 16:57

Ok, I will not implement such a feature. There are several reasons. The first is that it isn't one of Matroska's design goals to have bit-identical streams after putting content into Matroska and extracting it from it again. Matroska has always been about being a comprehensive storage container for a multitude of content types, and efficiency has also been at least a secondary goal. If the AUDs are not neccessary for playback from containers other than MPEG-2 (E)VOB or whatever then there's no reason to keep them when you put a stream into a Matroska container.

A third reason is that it is technically impossible (or nearly so) to keep the stream bit-exact. For example, in the raw h.264 streams there are AUDs before the first SPS and PPS NALUs. However, the SPS and PPS NALUs are combined into the AVCC which is in turn stored in Matroska's CodecPrivate element (the same is done for storage of h.264 inside MP4 files). There's simply to space for AUDs in the AVCC.

However, it might be possible to modify mkvextract to create AUDs on its during extraction. There would be a separate option which turned this feature on, just like there's such an option in x264. The question is: how important is such a feature? I don't have much free time, and I'd rather not waste it on a feature that no one except one or two people might find useful.

madshi

22nd August 2008, 17:24

A third reason is that it is technically impossible (or nearly so) to keep the stream bit-exact. For example, in the raw h.264 streams there are AUDs before the first SPS and PPS NALUs. However, the SPS and PPS NALUs are combined into the AVCC which is in turn stored in Matroska's CodecPrivate element (the same is done for storage of h.264 inside MP4 files). There's simply to space for AUDs in the AVCC.
I agree about AVCC.

But: IIRC earlier versions of mkvmerge stripped SPS and PPS NALUs from the frame data. At that time it made sense to prepend the codec private data when demuxing. But I think you changed mkvmerge to not strip SPS and PPS, anymore. Right? So I think prepending the codec private data in mkvmerge doesn't really make sense, anymore. What do you think?

However, it might be possible to modify mkvextract to create AUDs on its during extraction. There would be a separate option which turned this feature on, just like there's such an option in x264. The question is: how important is such a feature?
That is a good question and to be honest I'm not sure about the answer. What I can say is that my own tool (eac3to) depends on the AUDs as frame delimiters. So my tool cannot handle h264 bitstreams without AUDs in them. Now of course I could rewrite my tool to add support for h264 streams without AUDs in them, but to be honest having AUDs in the stream makes life so much easier. No need to write complicated algorithms to find out which slices belong together and which don't, when there are AUDs in the stream...

Mosu

22nd August 2008, 17:34

I agree about AVCC.

But: IIRC earlier versions of mkvmerge stripped SPS and PPS NALUs from the frame data. At that time it made sense to prepend the codec private data when demuxing. But I think you changed mkvmerge to not strip SPS and PPS, anymore. Right? So I think prepending the codec private data in mkvmerge doesn't really make sense, anymore. What do you think?

True, but mkvextract has to scan the stream before it can decide whether or not the AVCC has to be prepended or not. As no program so far has had a problem with multiple SPS and PPS NALUs (as long as they are identical!) I haven't seen the need for more complicated NALU scanning code.

That is a good question and to be honest I'm not sure about the answer. What I can say is that my own tool (eac3to) depends on the AUDs as frame delimiters. So my tool cannot handle h264 bitstreams without AUDs in them. Now of course I could rewrite my tool to add support for h264 streams without AUDs in them, but to be honest having AUDs in the stream makes life so much easier. No need to write complicated algorithms to find out which slices belong together and which don't, when there are AUDs in the stream...

I see, but I'm afraid that the reasons I've stated (especially space efficiency) are more important to me ;) Most tools I know do not write AUDs by default (or cannot do it at all). So you cannot rely on AUDs being present in eac3to.

madshi

22nd August 2008, 18:04

True, but mkvextract has to scan the stream before it can decide whether or not the AVCC has to be prepended or not. As no program so far has had a problem with multiple SPS and PPS NALUs (as long as they are identical!) I haven't seen the need for more complicated NALU scanning code.
Yes, that's why I said that it's not so important. I just find it cosmetically ugly to have duplicate SPS/PPS in the demuxed stream... :)

I see, but I'm afraid that the reasons I've stated (especially space efficiency) are more important to me ;) Most tools I know do not write AUDs by default (or cannot do it at all). So you cannot rely on AUDs being present in eac3to.
Most original streams I'm seeing (HD DVD, Blu-Ray, broadcasts) have AUDs in them. So relying on AUDs was not a problem so far. The only problem I'm having is that eac3to can not handle h264 streams demuxed by mkvextract. But I understand that space saving is important for you. And adding a new option is always a lot of work. I know that... :(

Mosu

22nd August 2008, 18:29

Most original streams I'm seeing (HD DVD, Blu-Ray, broadcasts) have AUDs in them. So relying on AUDs was not a problem so far. The only problem I'm having is that eac3to can not handle h264 streams demuxed by mkvextract. But I understand that space saving is important for you. And adding a new option is always a lot of work. I know that... :(

Probably because all three use MPEG program or transport streams. I'd guess that most direct encodings into MP4 or raw streams do not contain AUDs though.

madshi

22nd August 2008, 18:56

Probably because all three use MPEG program or transport streams. I'd guess that most direct encodings into MP4 or raw streams do not contain AUDs though.
Yes, that's probably right.

Mosu

8th September 2008, 17:11

Hey guys,

here's another release of mkvtoolnix, 2.3.0 this time. There are a couple of new features and a few important bug fixes along with the smaller improvements and changes. The change description from freshmeat.net reads as follows:

Newly supported features include DTS-HD tracks (both "high definition" and "master audio"), Ogg Kate text subtitles, skipping of ID3 tags in AAC and AC3 files, Vorbis-in-AVI, delaying any track type and floating point WAV files. Several bugs were fixed including timecode handling for various track types and use cases, A/V desynchronization in VOBs, wrong VobSub packets and more.

Please note that with 2.3.0 I stop providing binaries for a couple of distributions myself. These include: Ubuntu 6.06 and 6.10; OpenSuSE 10.0; Windows 95/98/ME/NT (meaning that there will be no more
non-Unicode binary for Windows). This does not mean that mkvtoolnix cannot be built on these platforms, just that you'll have to do it yourself.

A note for those who want to compile mkvtoolnix themselves: mkvtoolnix' library requirements have changed slightly. It now uses Boost's regex library instead of the PCRE library. mkvtoolnix can be linked against wxWidgets 2.6.x and 2.8.x as long as the 2.8 version has been built with 2.6 compatibility enabled (building definitely fails with 2.8 without 2.6 compatibility).

Here are the links:

...to the home page:

http://www.bunkus.org/videotools/mkvtoolnix/

...to the source code:

http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-2.3.0.tar.bz2

...to the Windows binary:

http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-2.3.0-setup.exe

As always, binaries for other Linux and Unix distributions are available from the home page.

Last but not least the full ChangeLog since the previous release 2.2.0:

------------------------------cut------------------------------
2008-09-08 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: all: On Unix/Linux rpath linker flags have been removed again (they were actually removed before the release of v2.3.0).

2008-09-07 Moritz Bunkus <moritz@bunkus.org>
* Released v2.3.0.

2008-09-06 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: improved the timecode calculation for MP3 tracks read from MP4 files. Another part of the fix for bug 165.

2008-09-03 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: mkvmerge honors the timecode offsets of all streams in a MPEG program stream (e.g. VOB file) fixing audio/video desynchronization. Fix for bug 295.

2008-08-30 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: Switched from the PCRE regular expression library to Boost's RegEx library.

2008-08-23 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: DTS-in-WAV handling (14 to 16 bit expansion)was flawed. Fix for bug 288.
* mkvmerge: new feature: Added support for Vorbis in AVI (format tag 0x566f). Fix for bug 271.
* mkvmerge: new feature: Added support for PCM tracks withfloating point numbers (CodecID A_PCM/FLOAT/IEEE). Patch byAurelien Jacobs (see AUTHORS).

2008-08-21 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The fix to the timecode handling for AVC tracks in MP4 files from 2008-04-16 caused certain other MP4 filesto not be read correctly. The video tracks were found, but no frames were read. Fix for bug 294.
* mkvmerge: new feature: Added support for Ogg Kate subtitles. Patch by ogg.k.ogg.k@googlemail.com.

2008-08-20 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mmg: The option "--delay" was removed. The option "--sync" now only modifies the timecodes of a given track. mkvmerge does not pad audio tracks with silence. "--sync"works with all track types now, but using a stretch factor otherthan 1 with audio tracks might not work too well during playback. mmg's inputs for "Delay" and "Stretch by" can be usedwith all track types. Fix for bug 287.

2008-08-19 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: mmg outputs a more informative errormessage for known but unsupported input file types (e.g. ASF, FLV,MPEG TS) instead of the cryptic "file identification failed".
* mkvmerge: bug fix: The VobSub reader would sometimes read too many bytes for a single SPU packet. Part of a fix for bug 245.

2008-05-16 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Using BZIP2 compression resulted in broken streams. Patch by Aurelien Jacobs (see AUTHORS).

2008-05-15 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Improved support for WAV files biggerthan 4 GB which only contain a single DATA chunk and a wronglength field for this DATA chunk (e.g. eac3to creates such files).

2008-05-14 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Certain Matroska files with dis-continuous streams (e.g. subtitles) caused huge memory consumption. Fix for bug 281.

2008-04-22 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: mkvmerge will output a proper error message if it is called with ASF/WMV files instead of detecting other kinds of streams (e.g. AVC ES streams). Fix for bug 280.

2008-04-20 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed an assertion in the OGM reader occuringfor OGM files with embedded chapters. Fix for bug 279.
* mkvmerge: all: On Unix/Linux rpath linker flags are added for library paths given in LDFLAGS and configure's "--with-extra-libs" options.

2008-04-16 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed wrong timecodes for MP4 files thatcontain video tracks with B frames and edit lists. Fix for bug277. Patch by Damiano Galassi (see AUTHORS).

2008-04-14 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: mkvmerge will not strip leading spaces in SRT subtitles anymore.
* mkvmerge: bug fix: Tuned the file type detection for MPEG ESstreams. Fix for bug 265.

2008-04-03 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed writing to UNC paths on Windows. Fixfor bug 275.

2008-03-09 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Added support for skipping ID3 tags in AAC and AC3 files. Fix for bug 204.
* mkvmerge: new feature: Added support for DTS-HD (both "master audio" and "high resolution").
------------------------------cut------------------------------

Have a nice day :)

Mosu

nautilus7

8th September 2008, 17:14

Thanks a lot for the update! :)Newly supported features include DTS-HD tracks (both "high definition" and "master audio")You mean High Resolution... :p

EDIT: I believe to forgot to update the program version number to 2.3.0. It displays 2.2.0 in titlebar.

Mosu

8th September 2008, 17:31

Thanks for noticing; I'll update the binaries.

Mosu

8th September 2008, 17:55

Binaries re-built and uploaded.

NanoBot

9th September 2008, 00:50

Hi Mosu,

first of all :thanks: for the new version.

In addition I would like to ask if there are plans to support VC.1 elementary streams as a source format ? ATM the only way to use raw VC.1 streams with mkvmerge is to create a mkv file containing only the video with eac3to/gsdmux first and to import this mkv into mkvtoolnix.

C.U. NanoBot

SeeMoreDigital

9th September 2008, 09:16

Hi Mosu,

Any chance of providing an "button option" to keep the "Video Stream Level Signalling" for MPEG-4 Part-2/Part-10 video streams. Instead of having to write-in the code?

Many thanks

madshi

9th September 2008, 10:16

here's another release of mkvtoolnix, 2.3.0 this time. There are a couple of new features and a few important bug fixes along with the smaller improvements and changes.
Thank you!

buzzqw

9th September 2008, 10:23

thanks Mosu!

BHH

madshi

14th September 2008, 12:11

@Mosu, don't know if you're still using my old code for parsing DTS-HD streams. I've found new information in the meanwhile. Here's the proper code to find out the size of the DTS-HD blocks:

if GetBits(bits, 32) = $64582025 then // DTS-HD sync dword
begin
GetBits(bits, 8);
GetBits(bits, 2);
blownUpHeader := GetBits(bits, 1) = 1;
if blownUpHeader then begin
GetBits(bits, 12);
sizeOfDtsHdBlockInBytes := GetBits(bits, 20) + 1;
end else begin
GetBits(bits, 8);
sizeOfDtsHdBlockInBytes := GetBits(bits, 16) + 1;
end;
end;
This is exactly the way "proper" DTS-HD decoders parse DTS-HD blocks. Finding out which stream is DTS-HD Hi-Res and which is DTS-HD Master Audio is not as easy as I originally thought. If you must know that I can tell you how. But I guess you don't really need to know, do you?

Mosu

14th September 2008, 12:54

@Mosu, don't know if you're still using my old code for parsing DTS-HD streams. I've found new information in the meanwhile. Here's the proper code to find out the size of the DTS-HD blocks:

Thanks, I've updated my code accordingly. Do you happen to have a sample with the blown-up-header bit set to 1? I only have samples with the bit set to 0.

Finding out which stream is DTS-HD Hi-Res and which is DTS-HD Master Audio is not as easy as I originally thought. If you must know that I can tell you how. But I guess you don't really need to know, do you?

Right, mkvmerge doesn't care as it has no effect on the way the track is muxed.

Mosu

14th September 2008, 12:56

In addition I would like to ask if there are plans to support VC.1 elementary streams as a source format ?

That's still only a "maybe". I'd like to, but it's mostly a question of lack of time.

Mosu

14th September 2008, 12:57

Any chance of providing an "button option" to keep the "Video Stream Level Signalling" for MPEG-4 Part-2/Part-10 video streams. Instead of having to write-in the code?

Maybe, maybe not. Sample files, please?

madshi

14th September 2008, 15:07

Thanks, I've updated my code accordingly. Do you happen to have a sample with the blown-up-header bit set to 1? I only have samples with the bit set to 0.
I don't have any such samples. I think it's a feature which is not used currently. It's probably for future use, I guess.

Mosu

14th September 2008, 15:12

I don't have any such samples. I think it's a feature which is not used currently. It's probably for future use, I guess.

Ah ok.

ataraxia937

16th September 2008, 03:37

I have built a package of mkvtoolnix 2.3.0 for Leopard. It is universal, but will not work on 10.4 or earlier. It is built with bzip2, lzo, and FLAC support, but does not include the GUI for mkvmerge as I haven't been able to make it work.

MKVToolNix for Leopard (http://www.andrew.cmu.edu/user/rjkohler/mkvtoolnix-2.3.0-universal.pkg)

(I also built a package of ogmtools if anyone wants that: OGMtools for Leopard (http://www.andrew.cmu.edu/user/rjkohler/ogmtools-1.5-universal.pkg))

I did send email to Mosu about these but I figured I'd post them here also.

Ritsuka

16th September 2008, 09:08

Oh well, I did one too but forgot about it.
edit: now available on http://www.bunkus.org/videotools/mkvtoolnix/downloads.html#macosx

It contains the gui too and works on 10.4.
Hopefully Mosu could put it his site like the 2.0 I compiled some years ago. :)

SeeMoreDigital

17th September 2008, 20:33

Maybe, maybe not. Sample files, please?Hi Mosu,

What I'm proposing is already possible. Currently however, in order to retain the "Video Stream Level Signalling" for MPEG-4 Part-2/Part-10 video streams, you have to go to the "User Defined Options" and write "--engage keep_bitstream_ar_info" in the box provided.

What I'm proposing is a "check-box" implementation. Something like this: -

http://i38.tinypic.com/1j6wqr.png

Cheers

Mosu

17th September 2008, 20:43

What I'm proposing is already possible. Currently however, in order to retain the "Video Stream Level Signalling" for MPEG-4 Part-2/Part-10 video streams, you have to go to the "User Defined Options" and write "--engage keep_bitstream_ar_info" in the box provided.

Ah, that's what you meant. Nope, sorry, I won't add an option for this. The reason is that in Matroska all information on every level should be the same. What I mean is: with AVC and other video formats there's the aspect ratio information on the bitstream level and the aspect ratio information on the container level. These two should always be the same -- otherwise how should a player decide which information to use? (The container information obivously, but it's ambiuous.)

The --engage option is there for users who know what they're doing, but I don't want to make it too easy for unexperienced users to shoot themselves in their feet.

SeeMoreDigital

17th September 2008, 21:23

Okay.... I understand what you mean. Keeping both CLS (Container Level Signalling) and SLS (Stream Level Signalling) would present confusion :(

Just a thought... Would it be possible to retain the Stream Level Signalling and not have any Container Level Signalling?

Personally, I've never really liked the idea of storing aspect ratio signalling at the container level ;)

Mosu

17th September 2008, 21:50

Just a thought... Would it be possible to retain the Stream Level Signalling and not have any Container Level Signalling?

Not with mkvmerge, no. And I won't add such an option, sorry.

Mosu

18th September 2008, 09:43

I have built a package of mkvtoolnix 2.3.0 for Leopard.

and

Oh well, I did one too but forgot about it.

Thanks a lot to the both of you. I'm hosting both of your pakages on my download page (http://www.bunkus.org/videotools/mkvtoolnix/downloads.html#macosx) now.

Mosu

19th September 2008, 09:34

madshi

19th September 2008, 10:43

I've spent the last couple of days implementing support for VC-1 video tracks. mkvmerge can now read VC1 tracks from EVOBs and from VC1 elementary streams like the ones that EVODemux produces. mkvmerge can still not read ASF/WMV files. You should not attempt to read VC1 from AVIs yet as the timecodes will probably be wrong (will be taken care of this weekend).

What I haven't been able to test:

Sample/pixel aspect ratio. The sample files that I have only have a 1:1 sample aspect ratio or no display information extension at all; therefore any other sample aspect ratio will cause mkvmerge to output a warning.
Audio/video synchronization. Unfortunately I don't have a single sample with which I can properly test A/V sync.
Timecodes for progressive material. The samples I have all seem to be interlaced.
The samples I have all use frame units (start code 0x00 00 01 0d). None use field or slice units (start codes 0x00 00 01 0c and 0x00 00 01 0b respectively). mkvmerge will abort if it encounters those. I don't even know whether or not VC1 allows field or slice units at all or if this is just allowed in WMV9.

As you can see I definitely need more sample files :) So if you'd like to upload a couple to my FTP server I'd be very grateful. Especially ones that cause any problem with mkvmerge. Please only upload EVOBs and VC1 raw elementary streams; I cannot handle WMVs at the moment. The samples should be "big enough"; unfortunately this often means a size of 50 MB or more. My FTP server can take it though, so don't be shy.

Here's the Windows build with VC1 support: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.3.0-build20080919-1.rar
Thanks! A few hints:

(1) For aspect ratio use DISPLAY_HORIZ/VERT_SIZE in relation to MAX_CODED_WIDTH/HEIGHT. You should totally ignore the ASPECT_RATIO bitstream elements. Only this way aspect ratio works correctly.

(2) For best muxing each frame should consist of:

[00 00 01 0f [...]] [00 00 01 0e [...]] 00 00 01 0d [...] [00 00 01 0c [...]] [00 00 01 (1b-1f) [...]]
In other words: You must not strip the sequence headers. Furthermore each MKV frame should contain exactly one "00 00 01 0d" part. Each MKV frame should begin with either "00 00 01 0f" or "00 00 01 0e" or "00 00 01 0d".

(3) AFAIK there's no "temporal_reference" field in the VC-1 bitstream nor anything similar. So I think you should just increase timestamps constantly with each frame. Which is different to MPEG2 and h264 where timestamps can jump back and forth, depending on "temporal_reference" respectively "pic_order_cnt".

(4) I've never seen "00 00 01 0b" used yet in any HD DVD or Blu-Ray streams. But "00 00 01 0c" is rather common in interlaced HD DVD and Blu-Ray streams. When there's "00 00 01 0c", there's a "00 00 01 0d" first. You need to mux them both into one MKV frame. If you separate them, the MS VC-1 decoder will show artifacts.

(5) You can double check whether your muxes are correct by comparing your MKVs with those created by eac3to ("mkvinfo -v"). eac3to's VC-1 muxing has been tested with hundreds of HD DVDs and Blu-Rays and I'm not aware of any problems. For eac3to to successfully mux VC-1 you need the latest Haali Media Splitter to be installed (download link see "eac3to -test").

I'll upload a few samples.

Oh, a short question. How do I play back EAC3 without a hardware decoder on Windows? I "only" have the current CCCP installed, and MPC stalls on files with EAC3 sound tracks. AC3 playback is working, of course, ffdshow takes care of that.
The latest ffdshow tryouts version can decode E-AC3, as long as it's part of an EVO or m2ts container, I think. You need the very latest ffdshow, since this was added just a couple of days ago...

Mosu

19th September 2008, 11:08

Thanks! A few hints:

(1) For aspect ratio use DISPLAY_HORIZ/VERT_SIZE in relation to MAX_CODED_WIDTH/HEIGHT. You should totally ignore the ASPECT_RATIO bitstream elements. Only this way aspect ratio works correctly.

At the moment I simply use DISPLAY_HORIZ/VERT_SIZE as the values for Matroska's "display width/display height" fields. Anyway, all samples I have have identical DISPLAY_HORIZ/VERT_SIZE and MAX_CODED_WIDTH/HEIGHT values, so I can't test that way either ;)

(2) For best muxing each frame should consist of:

[00 00 01 0f [...]] [00 00 01 0e [...]] 00 00 01 0d [...] [00 00 01 0c [...]] [00 00 01 (1b-1f) [...]]
In other words: You must not strip the sequence headers. Furthermore each MKV frame should contain exactly one "00 00 01 0d" part. Each MKV frame should begin with either "00 00 01 0f" or "00 00 01 0e" or "00 00 01 0d".

Ah. At the moment I've implemented muxing in V_MS/VFW/FOURCC mode that Haali's Matroska muxer also writes (dunno which version of Haali's muxer I've installed; I did the muxing with graphedit: EVO as the source, Haali's muxer connected directly to the EVO's video output pin). This one is quite different, though. It strips all sequence headers and entrypoints from the frames and puts one instance of each into CodecPrivate behing the BITMAPINFOHEADER.

I don't like it all that much myself, but I didn't know that eac3to can mux VC1 into Matroska. I'll take a look at how eac3to muxes VC1 and adopt mkvmerge's output accordingly.

So the basic warning is: Don't use the current mkvmerge for anything you want to keep! The way it muxes WILL change!

(3) AFAIK there's no "temporal_reference" field in the VC-1 bitstream nor anything similar. So I think you should just increase timestamps constantly with each frame. Which is different to MPEG2 and h264 where timestamps can jump back and forth, depending on "temporal_reference" respectively "pic_order_cnt".

True, but depending on the FRMCNT and RFF fields/flags in the frames (in combination with the sequence header's INTERLACE flag) the frame's duration may be longer than 1/FPS. That's what Haali's muxer did, anyay...

(4) I've never seen "00 00 01 0b" used yet in any HD DVD or Blu-Ray streams.

That's goot :)

But "00 00 01 0c" is rather common in interlaced HD DVD and Blu-Ray streams. When there's "00 00 01 0c", there's a "00 00 01 0d" first. You need to mux them both into one MKV frame. If you separate them, the MS VC-1 decoder will show artifacts.

Ok. That should not be such a big problem.

(5) You can double check whether your muxes are correct by comparing your MKVs with those created by eac3to ("mkvinfo -v"). eac3to's VC-1 muxing has been tested with hundreds of HD DVDs and Blu-Rays and I'm not aware of any problems. For eac3to to successfully mux VC-1 you need the latest Haali Media Splitter to be installed (download link see "eac3to -test").

Will do.

I'll upload a few samples.

Thanks a lot, both for the files and the info.

The latest ffdshow tryouts version can decode E-AC3, as long as it's part of an EVO or m2ts container, I think. You need the very latest ffdshow, since this was added just a couple of days ago...

Ah, good to know. I'll install it.

madshi

19th September 2008, 11:15

At the moment I simply use DISPLAY_HORIZ/VERT_SIZE as the values for Matroska's "display width/display height" fields.
That's exactly the right way. I'm already uploading 2 files with funny aspect ratios.

Ah. At the moment I've implemented muxing in V_MS/VFW/FOURCC mode that Haali's Matroska muxer also writes (dunno which version of Haali's muxer I've installed; I did the muxing with graphedit: EVO as the source, Haali's muxer connected directly to the EVO's video output pin). This one is quite different, though. It strips all sequence headers and entrypoints from the frames and puts one instance of each into CodecPrivate behing the BITMAPINFOHEADER.
Earlier versions of Haali's muxer did behave that way. But that resulted in artifacts with some HD DVD movies cause in some HD DVD movies the sequence headers change in the middle of the movie. I've reported that to Haali and he changed his way of VC-1 muxing in newer versions of his muxer to the same way eac3to is using. I guess you have an old Haali version installed on your PC.

True, but depending on the FRMCNT and RFF fields/flags in the frames (in combination with the sequence header's INTERLACE flag) the frame's duration may be longer than 1/FPS. That's what Haali's muxer did, anyay...
That's correct.

nautilus7

19th September 2008, 11:47

Ah, good to know. I'll install it.
ffdshow builds on sourceforge don't support E-AC3, so install this build posted by albain here (http://forum.doom9.org/showthread.php?p=1185130#post1185130). It's his last test build.

You can also play raw E-AC3 streams.

Mosu

20th September 2008, 16:57

Alrighty, thanks for your tips and the files that you guys have uploaded. Here's a new build that implements proper VC1 muxing:

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.3.0-build20080920-1.rar

Have fun testing :)

STaRGaZeR

20th September 2008, 18:31

VC1 tracks will be muxed in V_MS/VFW/FOURCC mode right Mosu?

Mosu

20th September 2008, 18:38

Yes, the same way they're muxed by Haali's muxer / by eac3to. You need a current version of Haali's splitter from http://haali.net/mkv/

STaRGaZeR

20th September 2008, 23:59

Nice. I can remember reading something about Haali's muxer using V_VC1, but it was removed later on because of some incompatibility with Microsoft's WMVideo Decoder DMO, IIRC. So I assume V_MS/VFW/FOURCC is the correct mode for the VC-1 codec family.

Will you add Windows Media Audio formats support in the future?

Mosu

21st September 2008, 08:47

Maybe, maybe not. They're pretty low on my TODO list.

NanoBot

21st September 2008, 12:31

Hi,

thanks for the support of raw VC.1 tracks, but it looks like you have forgotten to include the never versions of some dlls in the update archiv ?

"Die Anwendung kann nicht gestartet werden, weil wxbase28u_gcc_custom.dll nicht gefunden wurde"

C.U. NanoBot

Eragon4ever

21st September 2008, 12:36

Install 2.3.0 and unpack the archive on top of it. The dlls are in the installer.

Mosu

21st September 2008, 12:44

Eragon's correct. This is a newer build of v2.3.0 which includes the newer wxWidgets version.

NanoBot

21st September 2008, 12:55

Hi,

thanks for the fast answer. I accidentially extracted the archiv to an existing 2.2 installation or an older of 2.3 installation, and of course this could not work :stupid:

I reinstalled from the actual 2.3 installer and extracted the archiv, and now everything works fine. I am going to test the VC1 import function :thanks:

C.U. NanoBot

shambles

21st September 2008, 15:47

mkvmerge can't seem to handle ac3/e-ac3 files that are 2gb or larger. it just does this:

mkvmerge v2.3.0 ('Freak U') built on Sep 17 2008 09:50:38
'E:\1.eac3': Using the AC3 demultiplexer.
'E:\1.eac3' track 0: Using the EAC3 output module.
The file 'E:\1.mka' has been opened for writing.
Muxing took 1 second.

i tried cutting the file so it was just over 2gb and muxing failed. then i tried cutting it so it was just under 2gb and muxing worked fine.

zeropc

21st September 2008, 16:02

here is the os x version of mkvtoolnix 2.3.0.

special thanks to ritsuki for compiling it

http://www.mediafire.com/?nyxccrlz62t

kurt

21st September 2008, 16:17

remuxing of evobs (vc1) is not possible, is it?

mkvmerge v2.3.0 ('Freak U') built on Sep 20 2008 17:46:07

Error: 'I64d' is not a valid file ID in '--track-order 0:I64d'.

the audio tracks also don't seem to be recognized...

I'm uploading a sample, will edit the link here...

Mosu

21st September 2008, 16:19

mkvmerge can't seem to handle ac3/e-ac3 files that are 2gb or larger.

Thanks for noticing, fixed in this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.3.0-build20080921-2.rar

Mosu

21st September 2008, 16:20

remuxing of evobs (vc1) is not possible, is it?

Yes, it is.

Error: 'I64d' is not a valid file ID in '--track-order 0:I64d'.

!? I'm guessing you're using mmg. Which Windows version are you using?

shambles

21st September 2008, 16:35

Thanks for noticing, fixed in this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.3.0-build20080921-2.rar

thanks :D works fine in the new build

yonta

21st September 2008, 16:56

Loading these files in mmg fails with v2.3.0-build20080921-2.
It worked with v2.3.0-build20080920-1.

sample1 (http://www.sendspace.com/file/t34ojj)
sample2 (http://www.sendspace.com/file/bi6xn4)

kurt

21st September 2008, 17:00

Yes, it is.

!? I'm guessing you're using mmg. Which Windows version are you using?
sorry my fault, I made a mistake during installation. vc1 recognition it is working now :)

Mosu

21st September 2008, 17:23

Loading these files in mmg fails with v2.3.0-build20080921-2.
It worked with v2.3.0-build20080920-1.

Thanks, fixed in this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.3.0-build20080921-3.rar

yonta

21st September 2008, 17:38

Thanks, fixed in this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.3.0-build20080921-3.rar

WOW!
You are fast!

Now mmg doen't hang but reads all tracks except AVC video?

Mosu

21st September 2008, 18:10

Now mmg doen't hang but reads all tracks except AVC video?

Doh! Fixed in http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.3.0-build20080921-4.rar

Tima

21st September 2008, 21:49

Devilman1

21st September 2008, 21:59

I try to download this last build (mkvtoolnix-unicode-2.3.0-build20080921-4.rar) but I always receive the message that the file is not found.

Bye

Carlo

Mtz

21st September 2008, 22:08

Maybe Mosu is working on a new build. Have some patience.

enjoy,
Mtz

Mosu

21st September 2008, 22:09

Some timecode-related issues:

1) I demuxed an AC3 stream from some MKV file, then extracted timecodes for it. When I try to remux this AC3 to separate MKV with it's own (well, corrected) timecodes, after the process completion mkvmerge warns me that frame count in AC3 is greater then count of provided timecodes.

I cannot reproduce this. I always get exactly as many timecodes in the extracted-timecodes-file as there are frames in the extracted AC3 file. Muxing the extracted AC3 files with the extracted timecodes does not result in a warning.

2) I demuxed two AC3 streams and two srt subtitles from the movie to separate MKA file. Now when I try to extract timecodes for any of these two AC3 streams, mkvextract returns a file with header only (no timecodes at all)! When extracting timecodes for these streams from the main movie, it works OK.

Are you perhaps using the wrong track IDs during extraction of the separate MKA files? They're definitely not the same as they're in the "big" original MKV file.

3)From mkvmerge documentation:

In this format each line contains a timecode for the next frame.

Shouldn't 'next' be 'current' here?

Depends on your point of view ;) I'm more of a "the next frame that will be read" person than a "I'm working with the current frame" thinking person. Anyway, each frame gets one timecode from the file.

Mosu

21st September 2008, 22:10

I try to download this last build (mkvtoolnix-unicode-2.3.0-build20080921-4.rar) but I always receive the message that the file is not found.

Doh, stupid me. That's because I built it, but I forgot to upload it. That's been fixed now :)

Tima

22nd September 2008, 17:52

I cannot reproduce this. I always get exactly as many timecodes in the extracted-timecodes-file as there are frames in the extracted AC3 file. Muxing the extracted AC3 files with the extracted timecodes does not result in a warning.
I can cut the source file. If an issure will remain with the smaller sample, I can upload it to you -- if you need.

Are you perhaps using the wrong track IDs during extraction of the separate MKA files? They're definitely not the same as they're in the "big" original MKV file.
Yes, I'm aware of this, and used correct IDs for extraction.

I cut a small sample and uploaded it to your ftp -- the file is called 'no-timecode_sample.mka'. It contains only one AC3 stream, and there's no timecode extracted for track with ID 1 :)

Depends on your point of view ;) I'm more of a "the next frame that will be read" person than a "I'm working with the current frame" thinking person. Anyway, each frame gets one timecode from the file.
Maybe it'd be okay to change 'next' to 'correspondnig' then? It seems to be a person_type-independent solution ;)

Mosu

22nd September 2008, 18:33

I cut a small sample and uploaded it to your ftp -- the file is called 'no-timecode_sample.mka'. It contains only one AC3 stream, and there's no timecode extracted for track with ID 1 :)

Thanks. I found the problem :) Fixed in http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.3.0-build20080922-1.rar

KoD

22nd September 2008, 20:14

Hello Mosu, thank you for the new version of mkvtoolnix.

Here is a little interface bug in mkvmerge that's been present in 2.2.0 and probably before, and could be easily fixed. It's not critical, but hey ! :)

How to reproduce it:

a) 2 mkv files that have the segment title set (and not to the same value) are needed. So, for instance fileA.mkv which has only one segment, and the segment title is "Title A", and fileB.mkv which also has only one segment, and its segment title is "Title B".
b) take fileA.mkv and drop it in mkvmerge.
c) in the "Global" tab, "Title A" can be seen in the "File/segment title" input field.
c) in the "Input" tab, we press either the "remove" or "rem all" button
d) if we go to the "Global" tab again, we see the "File/segment title" input field still shows "Title A"
e) while in the "Input" tab, we drop fileB.mkv in mkvmerge
f) in the "Global" tab, "File/segment title" input field still shows "Title A" (hasn't been updated to "Title B")

So, that would be it. I'm using mkvmerge on Windows, but I guess this behavior is not platform dependent.

What should happen is:
1. on pressing "remove" or "rem all", the "File/segment title" input field should be cleared
2. after such a remove operation, mkvmerge should still set the "File/segment title" input field when adding mkv files that have it to the input box

Mosu

22nd September 2008, 20:51

What should happen is:
1. on pressing "remove" or "rem all", the "File/segment title" input field should be cleared
2. after such a remove operation, mkvmerge should still set the "File/segment title" input field when adding mkv files that have it to the input box

No, I don't agree (and I've argued this point time and again). If you want to start over then you'll have to chose "File -> New". This will remove all tracks and clear all input fields. If you only use "Remove all" then mmg assumes you want to keep all the other settings as they are. There are people using mmg exactly that way, and I won't change this behaviour. Sorry :)

KoD

23rd September 2008, 10:39

Ah, I was not aware there was a File->New menu option ! :D

In this case there's no need indeed for clearing those fields when remove is pressed. :)

Mosu

25th September 2008, 13:29

Here's a new build with a couple of bug fixes in the VC1 code. Especially EVOBs with multiple VC1 video tracks are read correctly now.

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.3.0-build20080925-1.rar

STaRGaZeR

26th September 2008, 21:06

A request Mosu, can you add a 60000/1001 option?

yonta

4th October 2008, 02:09

Mosu, can you take a look at this sample (http://www.sendspace.com/file/yxqa5g)?
It's from a HDTV cap and 1080i@60 MPEG2 ES.
I try to load it in mmg and mmg gives that message I get when I load a AVC ES?

You're adding an AVC/h.264 elementary stream.......

I'm using 20080925-1 build.

Mosu

4th October 2008, 20:20

Please download this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.3.0-build20081004-2.rar It fixes file type detection for your file.

madshi

5th October 2008, 21:14

@Mosu, would it be easy for you to add a version resource to the win32 mkvmerge.exe and mmg.exe files? Or at least to the mmg.exe file? The reason I'm asking is that my "eac3to" tool contains an "is there a new mkvtoolnix beta build available?" online check. Currently I'm using "mkvmerge --version" to do this check. But it seems that sometimes mmg.exe has a later date in a new beta build compared to mkvmerge.exe (e.g. in latest beta build mkvmerge reports Oct 4, while mmg.exe seems to be Oct 5), and since I can't programatically read out the mmg.exe version number and compile date, my version check sometimes fails to work properly.

Mosu

6th October 2008, 15:10

Starting with http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.3.0-build20081006-12.rar all EXEs have VERSIONINFO resources. Here's such a resource for mkvmerge for a release version:

1 VERSIONINFO
FILEVERSION 2, 3, 0, 0
PRODUCTVERSION 2, 3, 0, 0
FILEFLAGSMASK 0x3f
FILEOS 0x4
BEGIN
BLOCK "StringFileInfo"
BEGIN
BLOCK "040904B0"
BEGIN
VALUE "CompanyName", "Moritz Bunkus"
VALUE "FileDescription", "mkvmerge"
VALUE "FileVersion", "2.3.0"
VALUE "InternalName", "mkvmerge"
VALUE "LegalCopyright", "Released under the GNU Pulic License http://www.gnu.org/licenses/gpl-2.0.html"
VALUE "OriginalFilename", "mkvmerge"
VALUE "ProductName", "MKVToolNix"
VALUE "ProductVersion", "2.3.0"
END
END
END

Builds between releases have their build date and number coded into "File Version" and "Product Version", e.g.
...
VALUE "FileVersion", "2.3.0-build20081006-12"
...

madshi

6th October 2008, 15:31

That's *very* nice - thank you! :)

Just a quick question: Is there a specific exe you're always updating in a new beta build? Or should I simply loop through all exes to make sure I find the newest one to be able to show the proper version information?

Mosu

6th October 2008, 17:23

I've modified my build and upload scripts to always put the same version information into all EXEs and to re-build all EXEs for a beta build. Each build has its own unique version/build number. Therefore you should not have to loop through all EXEs anymore.

PS: The information shown in mmg's "About" window and in "mkvmerge --version" might not correspond to the version information in the resource. Use the data from the resource. That's more reliable for the Windows port. (The reason is simple: time. Building mkvmerge so that its --version output is up to date takes about 5 minutes with my crappy build computer while simply relinking with newer resources is done in 15 seconds or so.)

madshi

6th October 2008, 17:37

Great, will update my version check accordingly. Thanks again!

madshi

6th October 2008, 17:39

P.S: You could change the "mkvmerge --version" code in such a way that it reads its own EXE version resource and then outputs that. As a result you'd never have to waste those 5 minutes, anymore. At least that's how eac3to's version display works... ;)

Mosu

6th October 2008, 18:10

True, but that's no cure because there's no such thing as resources on non-Windows operating systems :)

swaaye

6th October 2008, 23:04

I've noticed that mkvmerge is very slow when muxing to a network drive. On my gigabit LAN, it can only pull about 5 MB/s even when it is only writing to the network (reading sources from local system drive.) I can dump DVDs to network drives at 20-30 MB/s, on the other hand.

Is this due to small-sized write accesses causing tons of overhead perhaps? It's a curious thing.

Mosu

6th October 2008, 23:14

Yes, most likely. mkvmerge is not multi-threaded and does not use advanced read-ahead or caching mechanisms. Sorry, I don't have time to do everything.

swaaye

7th October 2008, 00:10

Yes, most likely. mkvmerge is not multi-threaded and does not use advanced read-ahead or caching mechanisms. Sorry, I don't have time to do everything.

No no. I'm not asking for anything, just mentioning what I've run into. Your app is great! I'm not exactly using it in a typical way and it's not a critical thing at all .

zeropc

8th October 2008, 09:01

mosu, is it possible to add full support of .m2ts container import?

this would save some big time demuxing ;)

Mosu

8th October 2008, 09:06

Maybe, maybe not.

madshi

8th October 2008, 11:39

There are 2 big problems with adding m2ts support to mkvtoolnix:

(1) Some audio tracks might need transcoding to make sense. E.g. there's no current standard to store TrueHD in MKV. So TrueHD would have to be transcoded to something else. Or alternatively the Matroska "official forces" would have to be asked to add an official method to mux TrueHD into MKV. But even if that happens, mkvtoolnix would still have to be able to strip the AC3 frames from the TrueHD stream. That's possible to do, but can't be developed in 5 minutes.

(2) Some Blu-Ray movies consist of multiple m2ts parts. Simply demuxing video/audio and remuxing them into MKV would result in audio slowly drifting out of sync throughout the whole movie because audio overlaps in these m2ts parts while video (usually) does not.

As a result I'm not sure if it's worth it for Mosu to add m2ts support. However, @Mosu, if you want to add ts/m2ts support, when you have any technical questions, feel free to contact me.

Mosu

8th October 2008, 13:12

(2) Some Blu-Ray movies consist of multiple m2ts parts. Simply demuxing video/audio and remuxing them into MKV would result in audio slowly drifting out of sync throughout the whole movie because audio overlaps in these m2ts parts while video (usually) does not.

Oh my frellin' god. Which idiot came up with that scheme!?

Anyway, adding MPEG TS support is one of the bigger projects left. I might tackle this one day, but that's more an "if I find the time and motivation" than a "when I find the time and motivation".

madshi

8th October 2008, 14:36

Oh my frellin' god. Which idiot came up with that scheme!?
Well, if you think about it, it does make some sense. Each of the m2ts parts must play on its own (this logic is mainly used for seamless branching titles). So at the beginning of each m2ts part video and audio are perfectly in sync. But since e.g. an AC3 audio frame is 32ms long and video frames are usually 41.7ms long there's a runtime mismatch between audio and video. So it's clear that either audio or video have to overlap a bit. That's ok for a Blu-Ray player, but of course a bit problematic for a demuxing/transcoding tool.

Mosu

8th October 2008, 15:09

Ah yes, I was thinking about repeated audio packets. That would have been stupid. Overlapping timecodes are fine, though.

Mosu

12th October 2008, 00:13

Hey Matroska users,

here's another release of mkvtoolnix, 2.4.0. New features include support for VC1 video read from elementary streams and MPEG program streams, Dirac video elementary streams, support for 7.1 channel EAC3 tracks and the extraction of Theora video tracks into Ogg files. Bug that were fixed include the handling of unknown tracks in Ogg files, the automatic garbage detection for AC3/MP3 tracks, the handling of DTS in MPEG program streams, (E)AC3 files bigger than 2 GB and many more.

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

...to the Windows installer:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-2.4.0-setup.exe

The Linux binaries that I provide myself (Debian, Ubuntu, OpenSuSE and Fedora Core) have already been uploaded and are available from the home page.

Here's the full ChangeLog since release 2.3.0:

------------------------------------------------------------
2008-10-11 Moritz Bunkus <moritz@bunkus.org>

* Released v2.4.0.

* mmg: bug fix: The chapter editor's function "save to Matroska file" was corrupting the target file in some cases. Fix for bug 307.

2008-10-06 Moritz Bunkus <moritz@bunkus.org>

* mkvmerge: bug fix: mkvmerge was only writing one reference block for real B frames. Patch by Daniel Glckner. Fix for bug 306.

* all: bug fix: The Windows uninstaller was not removing all start menu entries during uninstallation on Windows Vista. The installer now creates the start menu entries for all users instead of the current user only. Fix for bug 305.

2008-10-05 Moritz Bunkus <moritz@bunkus.org>

* mmg: bug fix: The "language" drop down box contained some entries twice or more. Fix for bug 304.

2008-10-04 Moritz Bunkus <moritz@bunkus.org>

* mkvmerge: bug fix: Incorrect usage of the iconv library caused some conversions to omit the last character of each converted entry (e.g. for the conversion from Hebrew to UTF-8). Fix for bug 302.

2008-09-25 Moritz Bunkus <moritz@bunkus.org>

* mkvmerge: enhancement: mkvmerge will use the timecodes provided by the MPEG program stream source file for VC1 video tracks.

2008-09-24 Moritz Bunkus <moritz@bunkus.org>

* mkvmerge: bug fix: Reading EVOBs with multiple VC1 video tracks was broken (all packets where put into a single video track).

2008-09-22 Moritz Bunkus <moritz@bunkus.org>

* mkvextract: new feature: Added support for handling SimpleBlocks for timecode extraction.

2008-09-21 Moritz Bunkus <moritz@bunkus.org>

* mkvmerge: bug fix: Reading raw (E)AC3 files bigger than 2 GB was broken.

* mkvmerge: new feature: Added support for Dirac video tracks.

2008-09-20 Moritz Bunkus <moritz@bunkus.org>

* mkvmerge: bug fix: Improved the detection of MPEG-1/-2 and AVC/h.264 video tracks in MPEG program streams (VOBs/EVOBs).

* mkvmerge: bug fix: Fixed reading DTS audio tracks from MPEG program streams (VOBs/EVOBs).

2008-09-19 Moritz Bunkus <moritz@bunkus.org>

* mmg: enhancement: Added the extensions "evo", "evob" and "vob" to mmg's "add file" dialog.

2008-09-18 Moritz Bunkus <moritz@bunkus.org>

* mkvmerge: new feature: Added support for muxing VC1 video tracks read from MPEG program streams (EVOBs) or raw VC1 elementary streams (e.g. as produced by EVODemux).

2008-09-17 Moritz Bunkus <moritz@bunkus.org>

* mkvmerge: new feature: Added support for 7.1 channel EAC3 files. Fix for bug 301.

2008-09-13 Moritz Bunkus <moritz@bunkus.org>

* mkvmerge: bug fix: Revision 3831 (the change to the "--delay" and "--sync" options) caused mkvmerge to no longer respect the delay caused by garbage at the beginning of MP3 and AC3 audio tracks in AVI files. The timecodes of such tracks are now delayed appropriately again. Fix for bug 300.

2008-09-12 Moritz Bunkus <moritz@bunkus.org>

* mkvmerge: bug fix: Unknown stream types in Ogg files (e.g. skeleton tracks) don't cause mkvmerge to abort anymore. They're simply ignored. Fix for bug 299.

* mkvextract: new feature: Added support for extracting Theora video tracks into Ogg files. Fix for bug 298.

* mkvmerge: bug fix: Fixed the frame type (key or non-key frame) detection for Theora tracks.
------------------------------------------------------------

Have fun :)

Regards,
Mosu

shon3i

12th October 2008, 11:01

Thanks :)

PS. can you update title of this topic and first post?

Mosu

12th October 2008, 11:08

Done.

excentro

12th October 2008, 17:38

Thank you.

video_magic

12th October 2008, 17:39

Hello Mosu and thankyou very much!

delacroixp

12th October 2008, 17:54

:thanks: much !

It's all good !
:):devil::D
Pascal

KoD

13th October 2008, 18:45

I noticed that mkvextract extracts chapters to utf-8 files with a signature, which is great.

However, when extracting chapters with mkvextract, the contents of a <ChapterSegmentUID format="hex"> element is made of illegal UTF8 characters. Is that the expected behavior ? I think the file is not a legal xml file in this case. And it can't be opened in a text editor either, it has to be opened in a Hex editor who doesn't care about the contents of the file. Even mkvmerge crashes when trying to load that xml chapters file.

<ChapterAtom>
<ChapterTimeStart>00:00:00.000000000</ChapterTimeStart>
<ChapterTimeEnd>00:01:00.000000000</ChapterTimeEnd>
<ChapterFlagEnabled>1</ChapterFlagEnabled>
<ChapterFlagHidden>0</ChapterFlagHidden>
<ChapterSegmentUID format="hex">_illegal_utf8_characters_happen_here</ChapterSegmentUID>
<ChapterUID>2647081373</ChapterUID>
<ChapterDisplay>
<ChapterString>Chapter Title Goes Here</ChapterString>
<ChapterLanguage>eng</ChapterLanguage>
</ChapterDisplay>
</ChapterAtom>

Btw, MKVExtractGUI was a collateral victim of the latest mkvtoolnix. Seems to not like the output of the cli utilities/libraries' calls anymore. Is the original author around ? If not, I'll have a look at the source code as there was another issue I did not like, it was replacing the utf-8 bom of extracted chapter files with a "?".

Mosu

13th October 2008, 18:57

I noticed that mkvextract extracts chapters to utf-8 files with a signature, which is great.

However, when extracting chapters with mkvextract, the contents of a <ChapterSegmentUID format="hex"> element is made of illegal UTF8 characters. Is that the expected behavior ? I think the file is not a legal xml file in this case. And it can't be opened in a text editor either, it has to be opened in a Hex editor who doesn't care about the contents of the file.

You're mixing things here. The XML file itself is encoded in UTF-8, that's correct. From the point of view of the XML layer the content of the ChapterSegmentUID element contains only 17 different characters: 0-9, A-F and spaces. All those are perfectly valid UTF-8 characters.

The fact that mkvmerge translates this into binary data is entirely another matter. This happens after the data has been removed from the XML container, and therefore XML doesn't care anymore what happens to it.

KoD

13th October 2008, 19:09

I see what you're saying. I'm not an expert in xml, so I'll take your word on that.

I've made an edit later on to that post. In this case, I'd only like to report that mkvmerge crashes when loading said chapters xml file that it has itself exported previously.

Mosu

13th October 2008, 19:14

Can you upload that chapter file somewhere, please?

KoD

13th October 2008, 19:26

I've sent you a PM with lots of details. Let me know if there's anything else needed. :)

Mosu

13th October 2008, 20:14

Thanks. Fixed the bug in mkvextract. Here's a new build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.4.0-build20081013-24.rar

KoD

13th October 2008, 20:24

Thank you. I confirm it works here too. And now MKVMergeGUI works again, as well. :D

NanoBot

13th October 2008, 21:14

Hi Mosu, hi everybody,

yesterday I began to create some mka files ( only audio ), which should contain one ore more DTS tracks. This worked fine in most cases, but some dts files where rejected by mkvmerge with the following error messages:

mkvmerge v2.4.0 ('Fumbling Towards Ecstasy') built on Oct 13 2008 21:05:53
'G:\DTS\test.dts': Using the DTS demultiplexer.
'G:\DTS\test.dts' track 0: Using the DTS output module.
The file 'H:\test.mka' has been opened for writing.
Warning: 'G:\DTS\test.dts' track 0: Skipping 3583 bytes (no valid DTS header found). This might cause audio/video desynchronisation.
Progress: 0%Warning: 'G:\DTS\test.dts' track 0: Skipping 3583 bytes (no valid DTS header found). This might cause audio/video desynchronisation.
Warning: 'G:\DTS\test.dts' track 0: Skipping 3583 bytes (no valid DTS header found). This might cause audio/video desynchronisation.

and lots more of that.

eac3to also complains that is it not able to identify the source file format. I am able to playback those DTS files with MPC_HC together with AC3Filter, both through spdif or analog, but the internal DTS dekoder of MPC_HC is playing them back with wrong speed and pitch ( same as a mka muxxed with Haali, see below ). Mediainfo reports about those files:

Audio
Format : DTS-HD
Format/Info : Digital Theater Systems
Bitraten-Modus : Variable
Kanäle : 6 Kanäle
Channel positions : Front: L C R, Surround: L R, LFE
Samplingrate : 44,1 KHz
Auflösung : 20 bits

As a comparision, those DTS files which don't make problems look like that:

Format : DTS
Format/Info : Digital Theater Systems
Bitraten-Modus : Constant
Bitrate : 1 411,2 Kbps
Kanäle : 6 Kanäle
Channel positions : Front: L C R, Surround: L R, LFE
Samplingrate : 44,1 KHz
Auflösung : 24 bits

I also tried to mux such a file to mka using Haalis gsdmux, this works, but when the resulting mka file has a total wrong playtime, and the playback is strange, e.g. the pitch of the audio is absolute incorrect. Then I tried to "repair" those files with DTSParser, but this doesn't help at all.

So my question is what is wrong about those files ? Is it the 20bit depth, or is it the bitrate flagged as variable ?

If it is helpful I am able to provide a sample of such a DTS file.

C.U. NanoBot

nautilus7

13th October 2008, 21:34

These are DTS-HD tracks, but if eac3to can't handle them, then they may be damaged. Can you post the eac3to log file?

NanoBot

13th October 2008, 23:35

The only answer from eac3to is

"The format of the source file could not be detected."

nautilus7

13th October 2008, 23:53

That among with the error log from mkvmerge tell me that your file is corrupted. Does it play as it is? Where did you find the dts track and how did you demux it? If it came from a disc, re-rip the disc and try again.

NanoBot

14th October 2008, 00:05

Yeah, I think reripping is the only solution. What makes me wondering is that ac3filter is able to play those files without problems.

Anyway, thanks for your attempted help.

NanoBot

14th October 2008, 23:41

Hi again,

as an exception, I will answer my own posting because I found the reason for my problems. If one of the moderators would be so kind, he might move all postings related to this subject to a new thread, perhaps in the audio encoding forum.

First of all, reripping the DTS audio CDs was not the solution, because the ripped dtswav files were okay. The problem was caused by the programs which are used to convert dtswav files to dts files. I tried three different programs, that's wav2dts, besplit and DTSParser, and for some reason, all of them set the frame size in newly produced dts files to 3585 byte instead of 3584 byte by mistake. I found that by comparing the DTS headers of one of the defective files to another DTS file, which are working fine. The informations on that website were helpful for me to point out the error:

http://wiki.multimedia.cx/index.php?title=DTS

Correct DTS file headers:

Frame Type 1 normal
NumOfSamples - 1 11111 31
CRCPresent 0 no
NumOfBlocks 0011111 31
FrameSize - 1 00110111111111 3583
ChannelConfig 001001 L,C,R,SL,SR,LFE
SampleRate 1000 44100Hz
BitRate 10110 1411,2 kBit/s
DownMix 0
DynamicRange 0
TimeStamp 0
AuxData 0
HDCD 0
External Descr 000
External coding 0
ASPF 1
LFE 10
Predictor history 1
Header CRC not present
Multirate inter 0
Version 0111
Copy history 01
Source PCM resolution 000 16 bit
Front sum 0
Surround sum 0
Dialog normalization 0000 none

Defective DTS file header:

Frame Type 1 normal
NumOfSamples - 1 11111 31
CRCPresent 0 no
NumOfBlocks 0011111 31
FrameSize - 1 00111000000000 3584
ChannelConfig 001001 L,C,R,SL,SR,LFE
SampleRate 1000 44100Hz
BitRate 10110 1411,2 kBit/s
DownMix 0
DynamicRange 0
TimeStamp 0
AuxData 0
HDCD 0
External Descr 000
External Coding 0
ASPF 1
LFE 10
Predictor History 1
Header CRC not present
Multirate inter 0
Version 0111
Copy history 01
Source PCM resolution 010 20 bit
Front sum 0
Surround sum 0
Dialog normalization 0000 none

Is it possible that the authors of all three programs did not notice that the relevant header field must contain the frame size - 1 ?

C.U. NanoBot

nautilus7

15th October 2008, 00:00

All you had to do was to use eac3to to convert your dtswavs to dts (you didn't tell you are dealing with such). :p eac3to works fine with them.;)

NanoBot

15th October 2008, 00:33

Hi nautilus7,

If it would have been so easy...

One of the problematic cds was this title:

http://www.cduniverse.com/productinfo.asp?pid=1280942&cart=785928301

When I feed the ripped dtswav to eac3to it is not able to identify the wav file as dtswav, it sees it as a normal two channel PCM wav:

D:\MPEG\EAC3TO>eac3to.exe f:\moody.wav g:\test.dts
WAV, 2.0 channels, 0:43:34, 16 bits, 1411kbps, 44.1khz
Reading WAV...
Writing WAVs...
Creating file "g:\test.L.wav"...
Creating file "g:\test.R.wav"...
This audio track has a constant bit depth of 16 bits.
...

D:\MPEG\EAC3TO>eac3to.exe f:\moody.wav
WAV, 2.0 channels, 0:43:34, 16 bits, 1411kbps, 44.1khz

D:\MPEG\EAC3TO>

C.U. NanoBot

nautilus7

15th October 2008, 00:43

Yes, 're right. Send a sample to madshi to add support for this type of dtswav if you want to.

NanoBot

15th October 2008, 00:49

I will ask him if he is interested, since there might be only a few of those problematic DTS CDs.

madshi

15th October 2008, 09:24

My best guess would be that the DTS track is faulty in itself. Normally if you extract the DTS track of a DTSWAV file you don't do any changes to the DTS bitstream. So if all those 3 programs you tried output a wrong framesize than this wrong framesize is most likely already wrong in the original source. And that's probably also the reason why eac3to doesn't even detect the track as being DTSWAV at all - because it's simply not a valid DTS(WAV) track.

NanoBot

15th October 2008, 14:18

ATM I could neither confirm nor deny if the problematic source DTSWAV files are faulty. Because of the 14 bit words and the little endianess used in DTSWAV, it is a little bit difficult for me to identify the relevant header bits in the DTSWAV files. Nevertheless I will try to check the source DTSWAV for the frame size indicated there. Do do that, I will try to define winhex templates for the headers of standard DTS and DTSWAV. This should make it much easier to analyze the header.

Adub

17th October 2008, 19:58

zeropc

18th October 2008, 12:50

anyone willing to make a os x version of the latest release???

thanks :)

lchiu7

19th October 2008, 22:31

This is a strange one. Using the 2.2.0 GUI I

This is the situation. Our local broadcaster transmits HD as H.264 with AC-3 audio over DVB-T. Files end up quite large 4G/hr so I want to compress them and remove the ads.

I can remove ads okay with tspacket editor but the resulting file has AC-3 packet errors which are not apparent when played but play havoc with programs like tsremuxer etc. It seems that the packet errors occur at cut points.

So I thought I would do the following.

1. Break up the file into each segment between ad breaks.
2. Compress each segment into h.264 using x264
3. demux the AC-3 audio from each segment using dgavcindex
4. Merge the compressed video with the original audio into a MKV container using mkvmerge.

This seems to work fine. dgavcindex outputs the AC-3 file with a name containing text like DELAY -234ms and mkvmerge reads that delay value and inserts it into the parameter for delays.

However I end up with 4-5 separate mkv files for the one show. What I want to do of course is have just one file.

Thought I could do that with mkvmerge and just merge the 5 MKV files together. While that works, the resultant file loses audio/video sync - in fact the sync is fine for the part of the video that comes from the first file, it loses sync after that. That is strange since each individual file is in sync - it's just the merged file that isn't.

Tried something else - that is, rather than create 5 files, create one file by using the append option for each MP4 file but taking note for each different audio file, marking the appropriate delay for it.

That also doesn't work. Audio/video goes out of sync after the first segment.

Finally tried just a DOS copy /b option to concatenate the 5 files together but the resultant file just plays up to the end of the first segment.

Any thoughts or ideas appreciated on what I could do now.

Thanks

Larry

Adub

20th October 2008, 00:04

lchiu7

20th October 2008, 01:33

One thing you could do is to do all of your editing in Avisynth using the trim() command. That way you will result in one video and audio file. If you want more information on how to do this, use search on this forum, or visit the Avisynth wiki. Right now it just sounds like you are doing it the hard way.

Alas it's a bit more complicated than that. I can edit the .ts files fine with tspacket editor and the resultant file plays fine with audio and video in sync. But the file is still 3G for 42 minutes.

But as soon as I compress the video and try to mux it back with the audio, the various programs I use including mkvmerge and tsremuxer complain about bad packets in the AC-3 stream and lose data. I am guessing it's the way tspacket editor is cutting the video perhaps.

So I end up with a file with AV out of sync

Breaking it up into its component pieces seems to fix that but I can't find a way to join them all back as noted above.

Will check out avisynth. I am guessing the best way is to frameserve the video to Virtualdub but will try a few things out.

[edit]

However still doesn't explain why merging several MKV files together, each which have in sync audio/video creates a file which has the audio/video out of sync. I would have thought the mkvmerge just joins the files together but clearly it must be doing other processing also.

[edit]

Seems like merging MKV files is a known bug in mkvmerge when each stream has different audio/video sync offsets. Solved the problem by muxing each stream as a separate file and them merging them with avimux

http://alexander-noe.com/video/amg/

Works fine and resultant merged stream has all audio/video in sync.

KoD

24th October 2008, 10:44

mkvtoolnix v2.40 achieves delay differently than previous versions.

1. mkvtoolnix prior to v2.40 would create silence and append it in front of the audio stream that the user would like to be delayed with a positive delay value. This is also what avi-mux-gui (amg) does.
2. mkvtoolnix v2.40 doesn't add silence to the audio stream anymore, it simply modifies the timecodes so that the first audio frame is played at a timestamp = the delay value.

Probably mosu hasn't tested what happens when you merge two such files with delayed tracks. Maybe mkvmerge or the mkvmerge GUI forgets that it should respect the delay value for the file that is going to be appended. Or maybe you're doing something wrong.

peck798

29th October 2008, 10:34

I am glad to see that

shambles

2nd November 2008, 12:19

mkvmerge or mkvextract seems to drop the last frame off some dts-hd tracks

sample: http://www.sendspace.com/file/iea1gz

when i mux it with mkvmerge and then extract, the resultant file is smaller than the original file (comparing in hex editor, it looks like just the last frame is missing)

strangely, it doesn't happen with every dts-hd file though

Mosu

3rd November 2008, 17:11

mkvmerge or mkvextract seems to drop the last frame off some dts-hd tracks

sample: http://www.sendspace.com/file/iea1gz

The file size difference between the original .dtshd and the merge-and-extracted file is 2720. This is NOT a full DTSHD frame for this file as they're all 2728 bytes long. mkvmerge drops incomplete frames.

shambles

4th November 2008, 10:23

hmm. that's fairly strange.. i cut the orig track to 5mb pieces and then ran the first piece through eac3to, and it dropped the last (incomplete) frame

running it through eac3to now keeps it intact too.. afaik eac3to should always drop the last frame if it's incomplete :confused:

Mosu

4th November 2008, 18:31

Ichiu7: another user had the same problems. I've solved his problems in a new build, and I guess that your problems with A/V desynchronisation should be gone with it as well. Here's the build:

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.4.0-build20081103-28.rar

Mosu

4th November 2008, 18:45

Okay, I am trying to split some mkv files of mine, using the "Enable Splitting...after timecodes:" option.

However, I continue to receive an error if I use the format "00:43:32.220000000,01:26:58.320000000". But when I remove the decimal digits, everything works fine. Is this a bug in the GUI? Because I am using the correct time codes format.

This is a bug in mmg, yes. You can shorten the number of decimals to 3, then mmg accepts your input. Meaning that "00:43:32.220,01:26:58.320" works. I'll have to fix the long format.

Oh, and also, if I do NOT link the files, and use the format "00:43:32,00:43:45,00:43:42,00:43:24", which is supposed to result in chunks (episodes) that are 43min 32 seconds long and so on an so forth, instead results in 5 files which are 43:40, 12 seconds, 1 second, 22 seconds, and then the rest of an hour and a half or so. NOTE: these are not the exact times that I used, but they are essentially the same, and it shows that the resulting behavior is faulty and does not follow as the guide to MKVMerge GUI explained the process.

The mkvmerge GUI guide is indeed misleading here. The way the timecodes work is that mkvmerge splits after the specific input timecode has been reached. They are not the duration or the timecodes in the output file (!). If you want to split a file into three pieces with roughly the same length and a fourth piece with the rest of the file then you'll have to use "00:43:32,01:27:04,02:10:36".

I'll have to change the guide's wording accordingly. Anyone got a suggestion which is not as misleading as it is now?

Since I did NOT linked the files, I expected the timecode to start from 0 after every split. I don't know if this happened, but the output was faulty anyways.

The linking option only affects the timecodes written to the output files, not the timecodes given on the command line as they refer to the whole stream as if it weren't split.

73ChargerFan

20th November 2008, 20:14

I'd like to request that mkvmerge GUI process WM_PAINT messages more frequently while muxing is happening (or what ever is blocking them?)

It can take half a minute to redraw the windows, and during that time, it looks like it crashed, it can block explorer (including network requests from around my house) and I can't switch between virtual desktops. I'm running XP Pro SP3 with a quad Q6600.

Thanks for all your hard work on mkvtoolnix. I use it all the time to mux blu-rays into mkv for use around the home.

delacroixp

21st November 2008, 11:08

I use it all the time to mux blu-rays into mkv for use around the home.
Awesome.

It's all good !
:):devil::D
Pascal

Emp3r0r

21st November 2008, 15:14

I'd like to request that mkvmerge GUI process WM_PAINT messages more frequently while muxing is happening ditto on Vista x64

boissy

24th November 2008, 18:52

Hello to all actives Users and Friends,
I just demux with TsMuxer a video file (H264 Codec) and an audio file (TRUE-HD Codec).
I wanted to select the audio file in the language I want to merge it with the video file using mkvmerge.
The mkvmerge opened my video file with .264 extention.
It could'nt open the audio file with .ac3 extention :devil:

:sly:

NjB

TheFluff

25th November 2008, 15:47

boissy

25th November 2008, 17:44

dolby truehd is not (yet?) supported in matroska, at least not by any known muxers. transcode to another lossless codec (flac comes to mind, it compresses better than truehd anyway) or extract only the ac3 part.
There's no ac3 part in the language I want.
Onlytruehd.
I'm affraid I'm obliged to transcode to another codec.
I nedd to know wich program can help me do this . :-)
The Eac3to and More GUI ask me command lines, and it's complicated.

:script:

NjB

73ChargerFan

27th November 2008, 07:30

KoD

27th November 2008, 09:58

"Always Save Log Files" option, to the working directory

Throw an error if the streams are of different lengths (e.g. one video, one or two audio streams). I accidentally muxed a 6 minute audio stream into a 5 minute video.:confused:

That's not an error. It's just that you were not paying attention to what you were doing and the result surprised you.

madshi

27th November 2008, 19:39

@Mosu,

what does mkvtoolnix do with WAV files that are bigger than 2GB (or 4GB)? Does it support them? You know, the WAV header is limited to 2GB/4GB. Could you please:

(1) Either ignore the size information in the header, if the WAV file is bigger than 2GB/4GB?
(2) Or add support for wav64 or rf64 files?

In any case there should be some "official" way to feed mkvtoolnix with a >4GB WAV/PCM file.

Thanks!

Edit: Just noticed that mkvtoolnix does in fact support >4GB WAV files. So all is fine! :)

Mosu

28th November 2008, 14:18

I'd like to request that mkvmerge GUI process WM_PAINT messages more frequently while muxing is happening (or what ever is blocking them?)

This build should work better for you: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.4.0-build20081128-31.rar

Mosu

28th November 2008, 14:31

Throw an error if the streams are of different lengths (e.g. one video, one or two audio streams). I accidentally muxed a 6 minute audio stream into a 5 minute video.:confused:

Usage error, I will certainly not check for things like this.

KoD

3rd December 2008, 10:04

I've noticed that mkvmerge doesn't see LPCM audio streams inside DVD VOBs. If seeing and muxing such VOB files could be implemented. it would be great. They're basicly PCM audio. Here is a 18MB MPEG2 video + LPCM audio sample cut from a DVD vob (it's a cell from a vob): http://www.mediafire.com/?ikvzichmjzm

madshi

3rd December 2008, 11:42

I've noticed that mkvmerge doesn't see LPCM audio streams inside DVD VOBs.
@Mosu,

LPCM streams in VOB files are marked with "stream_index & 0xf0 == 0xa0". Each PES LPCM data block has a 3 byte header. Here's how to read the header:

channels = buf[1] & 0x7 + 1;
bitdepth = (buf[1] & 0xc0) >> 6; // 0=16bit; 1=20bit; 2=24bit
samplerate = (buf[1] & 0x30) >> 4; // 0=48k; 1=96k; 2=192k
The actual LPCM data for 16bit tracks is stored as expected (in big endian). However, 20bit/24bit is stored rather strangely. Unfortunately I don't have any samples for 20bit and 24bit...

Please note that the header is different for EVO files!

Mosu

4th December 2008, 16:57

LPCM is not supported at all at the moment. So I don't know when/if I'll find the time to implement support for it.

Mosu

5th December 2008, 14:51

Hey,

time for the next release of mkvtoolnix, 2.4.1. There's only one new feature: support for SRT/SSA tracks in AVI files. One important bug has been fixed regarding the handling of timecodes during appending which should fix A/V sync issues with appended tracks for most people. A couple of smaller bugs have been fixed as well (see below for details).

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

...to the Windows installer:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-2.4.1-setup.exe

The Linux binaries that I provide myself (Debian, Ubuntu, OpenSuSE and Fedora Core) have already been uploaded and are available from the home page.

Starting with this release I provide pre-built packages for Fedora Core 10 (i386 and x86_64 architectures).

Here's the full ChangeLog since release 2.4.0:

------------------------------------------------------------
2008-12-04 Moritz Bunkus <moritz@bunkus.org>
* Released v2.4.1.
* Build system: bug fix: Configure does not use "uname -m" for the detection of the Boost libraries anymore but configure's "$target" environment variable. This fixes the Boost detection for cross compilation builds. Fix for bug 311. Patch by Dominik Mierzejewski (see AUTHORS).

2008-12-03 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: PCM audio tracks bigger than approximately 8 GB were cut off after approximately 8 GB.

2008-12-02 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: mkvmerge recognizes SRT subtitle files with timecodes that contain spaces between the colons and the digits and timecodes whose numbers are not exactly two or three digits long.

2008-11-28 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: mmg processes window events much more often during muxing.
* all: Updated the language code list from the offical ISO 639-2 standard.

2008-11-04 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Split timecodes with more than three decimals were not allowed even though the docs say that they are. They are now, as mkvmerge supports such timecodes.

2008-11-03 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Changed the way mkvmerge calculates the timecodes when appending files. Should result in better audio/video synchronization.
* mkvmerge: new feature: Added support for reading SRT and SSA/ASS subtitles from AVI files (fix for bug 64).

2008-11-01 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: mkvmerge's LZO compressor would segfault if mkvmerge was compiled against v2 of the LZO library and the v1 LZO headers were not present.

2008-10-29 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: SRT subtitle files are also handled correctly if the timecode lines do not have spaces around the arrow between the start and end timecodes.

2008-10-13 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix: Matroska elements with binary data were output as garbage in XML files.
------------------------------------------------------------

Have fun :)

Regards,
Mosu

spida_singh

5th December 2008, 15:02

Thanks for the update, just installed latest version. When running mkvmerge, i get an error stating mmg.exe has stopped working (Vista 32), had to revert back to 2.4.0, anyone else experiencing the same?

Mosu

5th December 2008, 16:06

All: The installer for v2.4.1 didn't include two DLLs (libebml.dll and libmatroska.dll). I've uploaded a new installer build to the same location: http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-2.4.1-setup.exe (size 4093126 bytes). I advise to re-download the installer and re-install mkvtoolnix with it.

spida_singh: As I said please download the new installer build. If it doesn't fix the problem for you then I'll have to investigate. Unfortunately I don't have a single Vista installation at home nor at work, so it might take me some time (because, as you may have guessed by now, I cannot reproduce those crashes on my XP nor on our 2003 Server at work).

spida_singh

5th December 2008, 16:29

All ok now! Thanks!

Mosu

5th December 2008, 18:23

Great. Thanks for the feedback.

73ChargerFan

7th December 2008, 05:20

Thanks, am testing. Ugggh, Kaspersky thinks the installation program is a trojan. This didn't happen with the earlier installs.

Mosu

7th December 2008, 10:57

Congratulations to Kaspersky -- yet another virus scanner with a false positive.

madshi

7th December 2008, 12:18

It's getting common these days... :mad:

Emp3r0r

8th December 2008, 21:02

Feature request: Can mkvmerge ignore data in it's own namespace within a chapter xml file? For example:<?xml version="1.0" encoding="utf-8"?>
<Chapters xmlns:x="http://custom-data-namespace">
<EditionEntry>
<x:Data>I should be ignored because I'm in my own namespace.</x:Data>
<EditionFlagHidden>0</EditionFlagHidden>
<EditionFlagDefault>0</EditionFlagDefault>
<ChapterAtom>...

Also, on a separate subject (http://forum.doom9.org/showthread.php?t=141848), can you elaborate on what it takes to support new formats in mkvmerge? I assume it is technically possible to mux any audio/video/subtitle format (including currently unsupported formats) into mkv, but does the complexity come in with how the data is interleaved in ebml (for later splitting)?

Mosu

8th December 2008, 23:45

Ugggh, Kaspersky thinks the installation program is a trojan.

As more users have reported this issue I've taken the time to investigate this thoroghly. My findings are that this is indeed a false positive. However, I've pulled the installer and provided a new build that Kaspersky and all other anti virus scanners thinks is clean.

You can read my full announcement (http://www.bunkus.org/videotools/mkvtoolnix/allegedly-backdoor-in-windows-installer-v2-4-1.html).

Dark Morford

8th December 2008, 23:48

Is there a way to get mkvextract 2.4.1 to output timecodes that aren't in scientific notation?

For example, running `mkvextract timecodes_v2 video.mkv 1:timecodes.txt` on a file recently gave me output like 999749
999790
999832
999874
999916
999957
999999
1.00004e+006
1.00008e+006
1.00012e+006
1.00017e+006
1.00021e+006
Other tools I use that used to work correctly now complain that timecodes are too close together; I assume they can't deal with the 'e+006' at the end and just see timecodes like 1.00004, 1.00008, and so on. I wrote a Perl script that converts the scientific-notation numbers back into "regular" numbers, but I still lose precision because everything gets rounded to the closest 10.

Is there a command-line option or something for mkvextract that tells it to just output regular numbers instead of the scientific ones? If not, can we get one in mkvtoolnix 2.4.2?

Eragon4ever

8th December 2008, 23:52

Did you send them the file in question so they can fix it? The email address is newvirus@kaspersky.com; just use "Possible false-positive" as header. Their support in this regard is pretty good, all my reports were taken care of in less than 24h.

P.S. My Kaspersky remained completely silent.

Mosu

9th December 2008, 00:21

Mosu

9th December 2008, 00:22

Did you send them the file in question so they can fix it? The email address is newvirus@kaspersky.com

Thanks for the idea, I just did.

Mtz

9th December 2008, 02:03

I like that "Use Me". I hope to not change it for the next fix, or change it to "Use Me, Please".
Thank you for this program!

enjoy,
Mtz

canTsTop

10th December 2008, 20:29

is it possible some how to mux not fully encoded audio file? example:

ffmpeg -i audio.wav -acodec ac3 -ab 640k audio.ac3

and then encoding starts run this

mkvmerge -o new_video.mkv old_video.mkv audio.ac3

so mkvmerge mux everything at speed of conversion of audio to ac3

Kurtnoise

10th December 2008, 20:37

you can use the ffmkv muxer for that...

FFmpeg -i audio.wav -acodec ac3 -ab 640k -i old_video.mkv output.mkv

Mosu

10th December 2008, 21:01

No, mkvmerge requires all files to be finished and seekable (meaning that it will never support reading files via other protocols, e.g. ftp or http).

73ChargerFan

11th December 2008, 02:08

is it possible some how to mux not fully encoded audio file?
I'm hard drive limited, and this would just thrash. I can run multiple muxing / encoding programs, but only one per hard drive.

doggersen

12th December 2008, 03:41

The "splitting" feature works very well. But is it possible to end up with just 1 output-file (instead of at least 2)?
If for example I would only be interested in 20 minutes in the middle of a video (everything coming before and after, I would like to leave out).

Thanks.

Mosu

12th December 2008, 09:49

No, that's not possible at the moment, and I don't think I'll implement something like that anytime soon.

spida_singh

12th December 2008, 13:00

Hi

I have been using mkvmerge to create my video and flac audio mkv's. They play perfectly fine on the pc, but, when I use java playstation media server to stream them across, I always get stutter every 1 second. I have asked the question to the developer of the java streaming tool, and awaiting his reply, I just wanted to make sure I was not doing anything wrong when creating the mkv in the first place. As this stutter occurs with any mkv file I create only when streaming. Any ideas why this could be happeneing? I set the correct framerate for the elementary stream, correct aspect ratio, add the audio flac file and mux. All ok until i want to stream it.

thetoof

14th December 2008, 09:15

How could I insert mkv files in another one, without appending them? I've seen this before... but I don't have the slightest idea how the chapters and file linking methods were combined.

Practical usage:
Episode start - Opening - Episode - Ending - Preview
Since "Opening" and "Ending" are the same for the whole series, I'd like to encode them only once and link them in the episodes to reduce overall size.
Timecode example (random numbers, it's just for the concept):
3 files to link : Episode, Opening, Ending
00:00-02:00 (Episode 00:00-02:00)
02:00-03:30 (Opening 00:00-01:30)
03:30-23:30 (Episode 02:00-22:00)
23:30-25:00 (Ending 00:00-01:30)
25:00-26:00 (Episode 22:00-23:00)

So, how can I put the UID values in the timecodes??

Thanks for any input.

Snake91

14th December 2008, 10:58

I don't know if it's possible, however can you add the possibility to add black boarders during playing? I think so it could be possibile to append stream with different resolution in the same container.
I am ripping The Dark Knight BD and I don't want to waste bitrate in the useless black boarders just for few IMAX scenes (but I don't want to cut them either XD), with these solution I could simply add boarders with a container option only when they are needed to not deform correct aspect ratio.

Daiz

14th December 2008, 13:41

I have a feature request: Could it be possible to include support for having both chapters and tags in the same .xml file?

The reason why I'm asking is because it's annoying that you can't give editions names in the chapters file, you have to do it with a separate tags file.

So if it was possible to have a file like this:
<?xml version='1.0' encoding='UTF-8'?>

<Chapters>
<EditionEntry>
<EditionFlagOrdered>1</EditionFlagOrdered>
<EditionFlagHidden>0</EditionFlagHidden>
<EditionFlagDefault>1</EditionFlagDefault>
<EditionUID>500030138</EditionUID>
<ChapterAtom>
[...]
</Chapters>
<Tags>
<Tag>
<Targets>
<EditionUID>500030138</EditionUID>
<TargetTypeValue>50</TargetTypeValue>
</Targets>
<Simple>
<Name>TITLE</Name>
<String>Normal</String>
<TagLanguage>eng</TagLanguage>
<DefaultLanguage>1</DefaultLanguage>
</Simple>
</Tag>
[...]
</Tags>

You could keep everything in one file, and mkvmerge could recognize <Chapters> and <Tags> from there and write them properly to the resulting file. It would be a lot simpler to handle multiple editions this way.

73ChargerFan

14th December 2008, 19:23

Practical usage:
Episode start - Opening - Episode - Ending - Preview
Since "Opening" and "Ending" are the same for the whole series, I'd like to encode them only once and link them in the episodes to reduce overall size.

Check out 101 things you never knew you could do with Matroska (http://www.mod16.org/hurfdurf/?p=8)

Chumbo

17th December 2008, 02:15

I ran into this today and just wanted to report it. The "Save command line" doesn't save the command line. It only saves this"mkvmerge" -o ""

What I did find is that if you use the "Show the command line" prior to using "Save command line" then it works. The same goes for "rem all" which doesn't clear the command line until you use "Show the command line."

I guess I would ask for a feature where the command line stuff gets updated as the UI is used so it wouldn't be necessary to show the command line first and then saving it. It would also be nice to clear it when removing all content. Thanks much for considering this.

Mosu

17th December 2008, 08:32

I ran into this today and just wanted to report it. The "Save command line" doesn't save the command line.

Fixed in this build:

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.4.1-build20081217-48.7z

Chumbo

17th December 2008, 17:49

Fixed in this build:

http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.4.1-build20081217-48.7z
Yep, it sure is. :) Thank you.

If it's not too much trouble, and if others find this helpful too, it would be great to have the full path of mkvmerge in the command line. Now it's just "mkvmerge" after it would be something like "D:\Program Files\MKVtoolnix\mkvmerge.exe" instead. Thanks for considering this.

Mosu

17th December 2008, 18:10

If it's not too much trouble, and if others find this helpful too, it would be great to have the full path of mkvmerge in the command line. Now it's just "mkvmerge" after it would be something like "D:\Program Files\MKVtoolnix\mkvmerge.exe" instead. Thanks for considering this.

Go to "File -> Options", click the "Browse" button in the "mkvmerge executable" section, select mkvmerge.exe, hit "Ok". From now on the full path will be used. The simple "mkvmerge" is just the default during installation.

Chumbo

17th December 2008, 22:36

Go to "File -> Options", click the "Browse" button in the "mkvmerge executable" section, select mkvmerge.exe, hit "Ok". From now on the full path will be used. The simple "mkvmerge" is just the default during installation.
Very cool. Thanks much. Sorry for not checking the options first.

Thunderbolt8

28th December 2008, 14:21

got a problem with extracting a flac file from a blu-ray which I remuxed to mkv: when I try to demux it with mkvextract then its missing about 40% of its size and length. the movie has a length of >2h20min, while the playtime for the demuxed flac track is only ~1h14min (~830mb size, 5.1, 16-bit). there is no error reported, it just seems that the progress bar suddenly jumps from 52% to complete.

Mosu

28th December 2008, 14:41

LeMoi

28th December 2008, 15:53

When I mux an mkv file from an x264 encoded video (in mkv container), resulting file still has all x264 infos (bitrate and all encoding parameters), but I remux the resulting file, these infos are lost, is there a way to keep them ?

Thunderbolt8

28th December 2008, 15:53

What happens when you remux the file with mkvmerge? Is the resulting file cut off as well? If not, does extracting from the remuxed file work?
when I only checkmark the flac track to remux to .mkv/.mka then I get the same problem as with demuxing, the resulting file has the same, too short length. the mkvmerge progress bar also does the same kind of jump shortly after half being through.

and I even got the same problem when trying to remux the whole file 1:1, everything, including the video, got cut off at that point. missing more than 10gb.

Mosu

28th December 2008, 17:16

Mosu

28th December 2008, 17:19

when I only checkmark the flac track to remux to .mkv/.mka then I get the same problem as with demuxing, the resulting file has the same, too short length. the mkvmerge progress bar also does the same kind of jump shortly after half being through.

and I even got the same problem when trying to remux the whole file 1:1, everything, including the video, got cut off at that point. missing more than 10gb.

Ok, next try. Please run mkvinfo on the source file and send me the output:

mkvinfo -s yourfile.mkv --redirect-output info.txt

Compress info.txt with your favourite compressor (7Zip, RAR, ZIP are all fine) and upload it to my FTP server.

Thunderbolt8

28th December 2008, 18:58

done, its file 'Thunderbolt8 doom9 info.txt' with 12,1mb size.

its funny, the info also stops after that time...although the duration of the movie is >2h20min

Mosu

28th December 2008, 20:05

Thanks for the upload. The file looks OK up to that point. My guess is that the file is somehow damaged at this position. libebml which is used by all my programs for reading Matroska files is not very good in dealing with damaged files, so I don't know if I can do anything about it.

You could try remuxing the file with graphedit and Haali's demuxer & muxer first and using mkvextract on the resulting file afterwards.

Thunderbolt8

28th December 2008, 20:43

hm how can it happen that such a file can be damaged? the only thing I did with it is copy it from here to there and play it :S

edit: checked the source, theres indeed a small glitch at that time. the video & audio stop for half a second and then jump forward a little again with a small graphical glitch (but still in sync afterwards). just how did it happen, the source was clean when I remuxed it back then.

Thunderbolt8

3rd January 2009, 14:48

just tried to mux a dts express track with mkvmerge, but I couldnt add it. isnt it supported yet?

Mosu

3rd January 2009, 15:09

What is DTS express? And how is it different from other DTS types?

madshi

3rd January 2009, 15:15

It's a low bitrate version of DTS. It does not have a conventional DTS core. Instead it consists of DTS-HD blocks, only. It's used for commentary tracks on some Blu-Ray discs. The same logic you're using to determine the size of DTS-HD blocks also works for DTS-Express. The only difference between normal DTS-HD tracks and DTS-Express tracks is that there are no DTS core frames in a DTS-Express track...

P.S: The one problematic thing for you is probably that you'd need to be able to find out the bitrate, respectively how many frames there are per second. In order to find that out, you'd need to extend the bit parsing a bit. I could give you the necessary information, if you want to add it to mkvtoolnix...

Mosu

3rd January 2009, 15:56

Definitely not supported yet. Don't know when I'll get around to it.

Jeff Flowerday

12th January 2009, 07:04

Is there an easy way to go in after the fact and rename a stream or change the language? I hate having to remux when I make a silly mistake.

delacroixp

15th January 2009, 12:59

Is there an easy way to go in after the fact and rename a stream or change the language? I hate having to remux when I make a silly mistake.
I do the same ... but there is no fix for 'silly mistakes' at this time !!!

It's all good !
:):devil::D
Pascal

Liisachan

15th January 2009, 15:15

One quick question: Looking for a binary for Windows (http://www.bunkus.org/videotools/mkvtoolnix/win32/), I see 2.4.0 is the last official release and 2.4.1 is in /pre and every 2.4.1 build looks like a pre-release. I think this confusing situation happened because of that false-positive problem of some un-cute anti-virus software. So which is the real official 2.4.1 now? build20081207-44 is the current recommended build for practical (non-experimental) purpose? Or the newest 2.4.1 (2.4.1-build20090108-55) is better? TYIA!

J0nThn

15th January 2009, 22:00

After testing my differents builds on MacOS X for a few months I'm pretty sure it works now (or at lest on my side :) ). And it's time to share it with anyone willing the cutting edge of MKVtoolnix on Mac.
It's a self-sufficient build.
And thanks to previous build available on bunkus.org, that helped a lot.

So you'll find below 2 links for downloading the last build I made from the Git repository.

http://superuploader.net/7c9770291530-Mkvtoolnix-2-4-1-2009-01-15-d6b09c0-dmg.html

Snowknight26

16th January 2009, 21:49

This isn't supposed to happen, is it?

+-> Pre-parsing FLAC file: 95%
+-> Pre-parsing FLAC file: 100%
+-> Pre-parsing FLAC file: 100%%
'G:\Encoding Tools\temp\parkrun.mkv' track 1: Using the MPEG-4 part 10 (AVC) video output module.

nautilus7

16th January 2009, 22:22

Good catch. :D

Mosu

18th January 2009, 17:50

Hey users,

I've released mkvtoolnix v2.4.2. The files are still being uploaded, but here's the announcement anyway.

This release contains a number of smaller bug fixes and a minor new feature. Nothing too exciting, I guess. The code has been reworked a bit behind the scenes so that I think that the next release will feature a German translation of all programs, and other translations will be easy to add if I find some volunteers.

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

...to the Windows installer:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-2.4.2-setup.exe

Here's the full ChangeLog since release 2.4.1:

------------------------------------------------------------
2009-01-17 *Moritz Bunkus *<moritz@bunkus.org>
* Released v2.4.2.

2009-01-15 *Moritz Bunkus *<moritz@bunkus.org>
* mkvmerge: bug fix: If subtitle files are appended to separate video files (e.g. two AVI and two SRT files) then the subtitle timecodes of the second and all following subtitle files were based on the last timecode in the first subtitle file instead of the last timecode in the first video file. Fix for bug 325.
* mkvmerge: bug fix: Due to uninitialized variables mkvmerge would report OGM files as having arbitrary display dimensions. Fix for*bug 326.

2009-01-08 *Moritz Bunkus *<moritz@bunkus.org>
* mkvmerge, mmg: enhancement: Implemented MIME type detection for attachments with libmagic on Windows.

2009-01-03 *Moritz Bunkus *<moritz@bunkus.org>
* mkvmerge: bug fix: If a Matroska file containing attachments was used as an input file and splitting was enabled then the*attachments were only written to the first output file. Now*they're written to each output file. Partial fix for bug 324.

2008-12-21 *Moritz Bunkus *<moritz@bunkus.org>
* mkvmerge: enhancement: Decreased the time mkvmerge needs for*parsing Quicktime/MP4 header fields.

2008-12-17 *Moritz Bunkus *<moritz@bunkus.org>
* mkvmerge: bug fix: The parser for the simple chapter format (CHAPTERxx=...) can now handle more than 100 chapters. Fix*for bug 320.
* mmg: bug fix: The commands "Save command line" and "Create*option file" did not save mmg's current state but the state it was*in when the command "Show command line" was last used or when mmg was started.

2008-12-13 *Moritz Bunkus *<moritz@bunkus.org>
* mkvmerge: bug fix: Fixed a crash (segfault) with MPEG-4 part 2 video if "--engage native_mpeg4" is used. Fix for bug 318.

2008-12-08 *Moritz Bunkus *<moritz@bunkus.org>
* Windows installer: The installer cleans up leftovers from old*installations during an upgrade. It doesn't write registry entries for an exe called "AppMainExe.exe" anymore. It asks whether or not the user wants a shortcut on the desktop. It does not install the document for base64tool anymore because base64tool itself isn't installed anymore either. Fixes for bugs 314, 315, 316 and 317.
* mmg: bug fix: Fixed a compilation problem with non-Unicode*enabled wxWidgets. Fix for bug 313.

2008-12-05 *Moritz Bunkus *<moritz@bunkus.org>
* mkvmerge: new feature: Added support for reading the pixel*aspect ratio from Theora video tracks.
------------------------------------------------------------

Have fun.

Mosu

Mosu

18th January 2009, 17:53

One quick question: Looking for a binary for Windows (http://www.bunkus.org/videotools/mkvtoolnix/win32/), I see 2.4.0 is the last official release and 2.4.1 is in /pre and every 2.4.1 build looks like a pre-release. I think this confusing situation happened because of that false-positive problem of some un-cute anti-virus software.

That's correct.

So which is the real official 2.4.1 now? build20081207-44 is the current recommended build for practical (non-experimental) purpose?

It was until a couple of minutes ago ;) Get 2.4.2 now.

Mosu

18th January 2009, 17:54

This isn't supposed to happen, is it?

+-> Pre-parsing FLAC file: 100%%

Thanks, will be fixed in the next release (2.4.3 or whatever it will be called).

Mosu

18th January 2009, 18:08

After testing my differents builds on MacOS X for a few months I'm pretty sure it works now (or at lest on my side :) ). And it's time to share it with anyone willing the cutting edge of MKVtoolnix on Mac.
It's a self-sufficient build.

Hey, thanks a lot. Could you please build a dmg for today's new release 2.4.2? I'd also like to link to it from my home page (or I could host it on www.bunkus.org as well, that's up to you).

sneaker_ger

18th January 2009, 18:18

Duh. That's definitely a bug that I'll fix. Even though mkvmerge probably understands it (it simply uses the C function "strtod") I don't want scientific notation to be used for timecode files. I'll see to it that the next release contains a fix for it.

Thx for the new version, but the bug with the timecodes like "1.00004e+006" still seems to exist. :confused:

Chumbo

18th January 2009, 20:06

Hey, thanks a lot. Could you please build a dmg for today's new release 2.4.2? I'd also like to link to it from my home page (or I could host it on www.bunkus.org as well, that's up to you).
Mosu,
The exe link in your signature is being detected as a Trojan by Bitdefender. Is this a false positive? I assume that file was scanned and verified clean already right? Thank you.

[EDIT]Found this post: http://forum.doom9.org/showthread.php?p=1222084#post1222084 which confirms it is a false positive. It would be great if you can add Bitdefender to not see this as well.

Mosu

18th January 2009, 20:22

I cannot do anything about the virus scanners in particular; last time there was a false positive reported by Kaspersky I simply upgraded my NSIS installation. I can't do that at the moment, it is already up to date.

What you or anyone else can do is send Bitdefender a mail asking them to test the file and update their signatures. I did that with Kaspersky last time, they responded quickly.

Mosu

18th January 2009, 20:51

Thx for the new version, but the bug with the timecodes like "1.00004e+006" still seems to exist. :confused:

Should be fixed in http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.4.2-build20090118-72-setup.exe

Chumbo

18th January 2009, 22:29

J0nThn

19th January 2009, 12:13

Hey, thanks a lot. Could you please build a dmg for today's new release 2.4.2? I'd also like to link to it from my home page (or I could host it on www.bunkus.org as well, that's up to you).

No problem. :)
I've uploaded here (http://jonthn.free.fr/MKVtoolnix/) a new DMG for the 2.4.2 release it's still Leopard and Intel only.
Link to the 2.4.2 build : http://jonthn.free.fr/MKVtoolnix/Mkvtoolnix-2.4.2_2009-01-17-e5d156a.dmg

And you can link to this directory without a problem. I'll try to maintain it in sync with the different release.

Also If anyone need this you can always find the version you're using by "reading the information" of the App like this :
http://thumbnails11.imagebam.com/2408/431fc824072419.gif (http://www.imagebam.com/image/431fc824072419)

sneaker_ger

19th January 2009, 12:19

Should be fixed in http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.4.2-build20090118-72-setup.exe

thx, works fine. Just one question to be sure:
The problem with these files only affects the extraction of timecodes, right? The mkv files created with the old versions are just fine, aren't they?

Mosu

19th January 2009, 13:26

No problem. :)
I've uploaded here (http://jonthn.free.fr/MKVtoolnix/) a new DMG for the 2.4.2 release it's still Leopard and Intel only.
Link to the 2.4.2 build : http://jonthn.free.fr/MKVtoolnix/Mkvtoolnix-2.4.2_2009-01-17-e5d156a.dmg

Great, thanks. I'm linking to your download directory from http://www.bunkus.org/videotools/mkvtoolnix/downloads.html#macosx now.

Mosu

19th January 2009, 13:27

thx, works fine. Just one question to be sure:
The problem with these files only affects the extraction of timecodes, right? The mkv files created with the old versions are just fine, aren't they?

That is correct, the timecodes in the files are fine.

Thunderbolt8

20th January 2009, 01:57

Mosu

20th January 2009, 09:45

I can guess that you are quite busy with other stuff as well aside from working on mkvmerge, but would it be possible for you to give the implementation of being able to mux those DTS-Express tracks some priority when working on mkvmerge? I'm asking, because they have been quite common recently, looks like they are about to become a possible standard for commentary or also original mono tracks.
would be great, thanks! :)

Maybe. I'd need some sample files, preferably both raw files and DTS Express inside a MPEG transport stream. Would anyone upload files somewhere, e.g. to my FTP server?

Oh, and is there a way to play back such tracks with software only? I don't have DTS capable hardware.

Liisachan

20th January 2009, 12:55

Thanks Mosu!

2008-12-08 *Moritz Bunkus *<moritz@bunkus.org>
* Windows installer: The installer cleans up leftovers from old*installations during an upgrade. It doesn't write registry entries for an exe called "AppMainExe.exe" anymore. It asks whether or not the user wants a shortcut on the desktop. It does not install the document for base64tool anymore because base64tool itself isn't installed anymore either. Fixes for bugs 314, 315, 316 and 317.

Speaking of which, I remembered that a long time ago I was in a trouble after installing MkvToolnix in a directory that is not exclusively for MkvToonlnix but with many other files, and when I ran the uninstaller, it deleted everything in that directory!

Since then, I always just unzip the installed w/ 7-zip and copy files manually, not using installer/uninstaller.

Incidentally, an even worse thing once happened to me with ac3filter uninstaller: I happened to install ac3filter files in Windows' system32, and then ac3filter's uninstaller deletes everything in system32. Oh the humanity~ I had no choice but to reinstall the OS.

Mosu

20th January 2009, 14:37

Maybe. I'd need some sample files, preferably both raw files and DTS Express inside a MPEG transport stream.

MPEG program stream is what I need, not transport stream -- my bad. mkvmerge does not handle transport streams.

nautilus7

20th January 2009, 14:50

MPEG program stream is what I need, not transport stream -- my bad. mkvmerge does not handle transport streams.DTS express only exists in Blu-ray (.m2ts) afaik. I can provide such samples if you want them.

Only dts express capable decoder i know is nero.

sneaker_ger

20th January 2009, 15:52

MKVMergeGUI only detects the "first" VOBs of DVDs correctly for me. (VTS_01_1.VOB, VTS_02_1.VOB, VTS_03_1.VOB etc.) For the others (VTS_02_2.VOB,VTS_02_3.VOB etc.) it always recognizes the video track as "AVC/h.264" instead of "MPEG-2".

http://img1.abload.de/img/mkvmergevobzca9.png

Thunderbolt8

22nd January 2009, 20:29

Maybe. I'd need some sample files, preferably both raw files and DTS Express inside a MPEG transport stream. Would anyone upload files somewhere, e.g. to my FTP server?

Oh, and is there a way to play back such tracks with software only? I don't have DTS capable hardware.
this could be hard, since there are hardly any new BDs using mpeg2 any more :S
regarding the playback, best would be to ask madshi about it. guess he knows what'll work best there.

Snowknight26

24th January 2009, 06:04

There are commas at the end of the language names for cpe, cpf, and cpp - seem a bit out of place.

Also, why are there multiple duplicate languages with different orders?
For example:

zha (Chuang; Zhuang)
zha (Zhuang; Chuang)

Edit: Actually, regarding cpe, cpf, and cpp, it seems as if whatever was supposed to be after the comma is missing (assuming you're using ISO 639-2 codes (http://en.wikipedia.org/wiki/List_of_ISO_639-2_codes#C)).

Mosu

24th January 2009, 11:22

There are commas at the end of the language names for cpe, cpf, and cpp - seem a bit out of place.

Thanks for noticing.

Also, why are there multiple duplicate languages with different orders?
For example:

zha (Chuang; Zhuang)
zha (Zhuang; Chuang)

Because they're also listed multiple times on the registration authority's website, http://www.loc.gov/standards/iso639-2/php/code_list.php

Snowknight26

30th January 2009, 06:33

mkvmerge doesn't seem to detect 44.1KHz AC3 files that I made with eac3to. Only after resampling to 48KHz does mkvmerge accept them.

Also, what's CodecPrivate? Every time I try to append two files with differing CodecPrivate lengths (40 and 41), the resulting mkv has horrible corruption. What sets the CodecPrivate value/field/info, and why are the two different? I had a look through http://haali.cs.msu.ru/mkv/codecs.pdf (oh hey, is that a mistake? He writes 'minus' but shows '+') but I still don't understand much about it.

Mosu

1st February 2009, 00:40

mkvmerge doesn't seem to detect 44.1KHz AC3 files that I made with eac3to. Only after resampling to 48KHz does mkvmerge accept them.

I've spoken with madshi about this problem, and it seems that the library eac3to uses (libAften) writes corrupt AC3 files for 44.1 kHz files. This is not a bug in mkvmerge.

Also, what's CodecPrivate?

CodecPrivate is the name of a Matroska element that contains codec initialization data that is private for the codec. The codec could store information about the encoded stream that is neccessary for decoding.

If you append two tracks for which this data differs then the result is most likely that the decoder cannot decode at least part of the resulting file, and that's what you're experiencing. In such cases you cannot append those tracks without reencoding at least one of them, maybe even both.

Tima

1st February 2009, 22:20

Tried to mux an AC3 with +28362ms delay -- seems it doesn't work.

Mosu

1st February 2009, 22:28

Look at the resulting file with mkvinfo. The timecodes should be properly adjusted (e.g. the audio track should start at 00:00:00.028362), but I guess that the playback application cannot cope with 28 seconds of missing audio data (this is rather common, and there's nothing I can do about it).

Tima

2nd February 2009, 01:42

madshi

2nd February 2009, 09:13

I've spoken with madshi about this problem, and it seems that the library eac3to uses (libAften) writes corrupt AC3 files for 44.1 kHz files. This is not a bug in mkvmerge.
It was my fault after all. The bug has been fixed in the latest eac3to version.

Guess it should be addressed to Haali or MPC developer(s) :)
No containers nor splitters like such big delays. Instead you should simply delay the AC3 bitstream using delaycut or eac3to. It's simply enough...

Tima

2nd February 2009, 19:22

No containers nor splitters like such big delays. Instead you should simply delay the AC3 bitstream using delaycut or eac3to. It's simply enough...

Thanks, I'll try it =) But anyway it's a quick'n'dirty solution -- the proper way is submit a bug for Haali.

madshi

2nd February 2009, 19:55

Thanks, I'll try it =) But anyway it's a quick'n'dirty solution -- the proper way is submit a bug for Haali.
No. IMHO the proper way is to edit the bitstream and not to submit a bug report. We don't even know for sure if Haali could change anything in the first place. It could also be the general DirectShow pipeline which might not like such situations. I don't know what the specs say, but AFAIK it's common "good practice" to not use such high delays in a container. Small delays are perfectly fine, but not multiple seconds.

khagaroth

21st February 2009, 21:03

Before you release 2.5, you should check translation support on Windows, because, if it's supposed to work in todays pre build (2.4.2-83), it's not.

Mosu

21st February 2009, 21:10

Details, please. It works nicely for myself (German Windows XP SP3).

1. Which Windows version are you using, and which language does it have?
2. Try switching to German, restarting, in mmg's options dialog. Does this change the language?
3. What else have you tried?

khagaroth

22nd February 2009, 10:58

I have Czech XP SP3. Setting the language in options dialog doesn't have any effect, the GUI is still in English after restart. The registry entry ui_locale does change to german, so that's not the problem. I finally got it working by setting the variable LC_MESSAGES = German (it should be "de", not "German", if you use "German", it will break GTK even for German users, but fortunately after renaming the locale folder from german to de it can be set to de), but that breaks my GTK apps, that I have set to display in Czech (LC_MESSAGES=cs). So for now, if I wanted to run it in German without breaking my other programs, I would have to use a bat file. On another note, I tried to create locale\cs\LC_MESSAGES\mkvtoolnix.mo with a few strings in Czech and it works with my LC_MESSAGES=cs.

Mosu

22nd February 2009, 11:33

So the problems are mkv* only setting LANG but not LC_MESSAGES and using the locale name as returned by GetLocaleInfo() instead of the ISO639 names. Please give this build a try: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.5.0-build20090222-84-setup.exe

khagaroth

22nd February 2009, 14:22

Yes, this one works. How about adding an option to use the system default (with a fallback to English if not available) and automatic enumeration of languages in locale folder. That way it wouldn't be necessary to change the code every time you add new language.

Mosu

22nd February 2009, 14:44

Yes, this one works. How about adding an option to use the system default (with a fallback to English if not available)

mmg already does exactly that.

and automatic enumeration of languages in locale folder. That way it wouldn't be necessary to change the code every time you add new language.

Nope, sorry.

Mosu

22nd February 2009, 14:53

Clarification. mmg detects the system's language by calling the GetLocaleInfo() function. This returns a string like 'English' or 'German', not the two-letter code that Unixish apps (like GTK) need.

Unless the user sets a specific language in mmg's option dialog mmg uses the system's default language, but only if mkvtoolnix contains a translation for that language. Otherwise it should fall back to English.

khagaroth

22nd February 2009, 17:36

Mosu

22nd February 2009, 17:50

Found another translation problem, this time with commandline tools. On Windows the GUI and commandline use different encodings, on Czech windows it's CP1250 for GUI and CP852 for commandline, but right now the conversion is always UTF-8 -> CP1250, so the text in commandline is garbled.

That's not only a problem for the Czech version but for the German version as well. You can always specifiy the charset to use with "--command-line-charset" and "--output-charset". I will probably not fix this.

Mosu

22nd February 2009, 20:45

Hey users,

I've released mkvtoolnix v2.5.1 today. In case you're wondering about 2.5.0: it was supposed to be released yesterday, but bugs were noticed and fixed after the tagging and therefore I decided to skip an official release of 2.5.0 and go straight to 2.5.1.

This release contains fully translatable versions of the tools and a German translation of them. The second new feature is a fine-grained control over file attachments both in mkvmerge and in mmg. A couple of smaller bugs where fixed as well.

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

...to the Windows installer:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-2.5.1-setup.exe

Here's the full ChangeLog since release 2.4.2:

------------------------------------------------------------
2009-02-22 Moritz Bunkus <moritz@bunkus.org>
* Released v2.5.1.
* mmg: bug fix: Fixed the selection of the translation to use if the LC_MESSAGES environment variable has been set on Windows.

2009-02-21 Moritz Bunkus <moritz@bunkus.org>
* Released v2.5.0.
* mmg: bug fix: Fixed a crash during the check if files could be overwritten by the next mux. Possible fix for bugs 335 and 336.

2009-02-19 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mkvinfo, mkvextract, mmg: Made all those programs nearly completly translatable. Added a German translation for all four programs (only for the programs, not for the static documentation: man pages, the guide to mmg etc).
* mkvmerge, mmg: new feature: Added options ('-m' / '--attachments' and its counterparts '-M' / '--no-attachments') to mkvmerge for selecting which attachments to copy and which to skip and the corresponding controls to mmg.

2009-02-06 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed the detection of AAC files whose first AAC header does not start on the first byte of the file.

2009-01-19 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: It was possible to crash mmg by clicking onto the root element in the chapter editor.

2009-01-18 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix: During timecode extraction mkvextract wrote large timecodes in scientific notation.
------------------------------------------------------------

Have fun.

Thunderbolt8

23rd February 2009, 00:35

thanks.

why is it actally that way each time when I add a file from the root directory of a partition (e.g. from C:\ or D:\) so that the standard output path appears that this path then is listed with double '\\' ( C:\\ or D:\\)?

e.g. adding a file

Mosu

23rd February 2009, 11:20

sneaker_ger

23rd February 2009, 12:49

Thanks for the new version. Noticed one bug with the attachments: After you click "file"->"new" and add a file the attachments are not checked. Checking or unchecking them changes nothing in the output file. All attachments are copied anyway.

Mosu

23rd February 2009, 14:26

No, that's not inteded. The default should be that the attached files are checked when you add a file. Will be fixed soonish.

BTW: I hate wxWidgets. No, I hate how it behaves differently on Windows and Linux...

Snowknight26

24th February 2009, 18:44

FLAC file parsing still shows 100% twice (but it doesn't show 100%% anymore! :D). Also, any reason why all the windows have become much wider?

Mosu

24th February 2009, 18:48

They're wider in order to account for other languages. Most things are quite a bit longer in German than they're in English (e.g. "Add to job queue" vs "Zu Jobwarteschlange hinzufügen"), and those strings have to fit somehow. Also I prefer the muxing messages not to wrap as often.

sneaker_ger

25th February 2009, 18:04

Two suggestions:

1.) It would be nice to have a "Check/Uncheck all" option in the attachments
2.) It should be possible to extract just certain parts of a mkv. Now you have to write the whole file even if you just want to create a 10 second sample... (or I'm missing the option to do so.)

Mosu

25th February 2009, 18:24

Two suggestions:

1.) It would be nice to have a "Check/Uncheck all" option in the attachments.

I'll probably add that.

2.) It should be possible to extract just certain parts of a mkv. Now you have to write the whole file even if you just want to create a 10 second sample... (or I'm missing the option to do so.)

Maybe, maybe not; definitely not in the next couple of weeks.

liquidator87

26th February 2009, 10:11

I'm having this error when I try to start mmg or mkvmerge: "Error: The locale could not be set properly. Check the LANG, LC_ALL and LC_MESSAGES environment variables."
Those variables are all set to "en_US.UTF-8"

Mosu

26th February 2009, 10:50

See https://www.bunkus.org/bugzilla/show_bug.cgi?id=338

Mosu

28th February 2009, 18:01

Hey,

I've released mkvtoolnix v2.5.2.

This is mostly a bug-fix release with two minor new features.

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

...to the Windows installer:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-2.5.2-setup.exe

Some of the binaries are still being built and should be available
within the next two hours.

Here's the full ChangeLog since release 2.5.1:

----------------------------------------------------------------------
2009-02-28 Moritz Bunkus <moritz@bunkus.org>
* Released v2.5.2.
* installer: bug fix: If the installer is run in silent mode (switch "/S") then it will not ask the user whether or not to place a shortcut on the desktop, and that shortcut will not be created. Fix for bug 345.
* mmg: new feature: Added two buttons "enable all" and "disable all" to the list of attached files that enable / disable all attached files.
* mmg: bug fix: The action "File" -> "New" did not clear the internal list of attached files resulting in unexpected behaviour if files with attachments where added afterwards.
* mmg: bug fix: The button "remove all files" did not clear the list of attached files.

2009-02-26 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: new feature: Made mkvinfo's GUI translatable. Added a German translation for the GUI.

2009-02-25 Moritz Bunkus <moritz@bunkus.org>
* mmg: On Linux wxWidgets 2.8.0 and newer uses the GTK combo boxes which suck. A lot. Therefore mmg uses wxBitmapComboBoxes for wxWidgets >= 2.8.0 on Linux and normal wxComboBoxes in all other cases. wxBitmapComboBoxes are still drawn by wxWidgets itself (just like wxComboBoxes before 2.8.0) and offer much better functionality. Fix for bug 339.
* mkvmerge, mmg: bug fix: The MIME type autodetection for attachments was broken for paths with non-ASCII characters on non-UTF-8 encoded systems (mostly on Windows). Fix for bug 340.
* source: various fixes for compilation with wxWidgets 2.9.

2009-02-24 Moritz Bunkus <moritz@bunkus.org>
* all programs: bug fix: The locale was not detected properly often resulting in the program aborting with the message that "the locale could not be set properly". Fix for bug 338.
----------------------------------------------------------------------

Have fun.

hubblec4

1st March 2009, 11:29

Hello Mosu.

Thanks for your hard work and the best tool ever i have seen.

One question: is it possible to implement a feature to set all the subtitle from -Default track flag- "default" to "no" ?

sometimes i have a movie with more than 20 subtitles and no subtitle should be shown at startup the movie.
so i must set every subtitle from default to no.

hubble

hubblec4

1st March 2009, 11:41

Any plans to add the support for Bluray.sup and HD-DVD.sup in the future??

hubble

liquidator87

1st March 2009, 13:12

Could you please add the "uninstall" option to the makefile? It would be very useful

Mosu

1st March 2009, 13:29

No, I have other priorities at the moment. You have several options for making your life easier already:

1. Use a pre-built package
2. Build the package yourself (extract the source, rename "debian-upstream" to "debian", call "dpkg-buildpackage -rfakeroot")
3. Use checkinstall for building a package
4. Install into a separate directory (e.g. "./configure --prefix=/opt/mkvtoolnix-2.5.2")
5. Use stow (e.g. assuming that the stow directory is /usr/local/stow: "cd mkvtoolnix-2.5.2 ; ./configure --prefix=/usr/local ; make ; sudo make prefix=/usr/local/stow/mkvtoolnix-2.5.2 install ; cd /usr/local/stow ; sudo stod mkvtoolnix-2.5.2")

Mosu

1st March 2009, 13:33

One question: is it possible to implement a feature to set all the subtitle from -Default track flag- "default" to "no" ?

Possible? Yes. But very, very low on my priority list.

Any plans to add the support for Bluray.sup and HD-DVD.sup in the future??

Not at the moment.

Mosu

7th March 2009, 16:03

Hey,

I've released mkvtoolnix v2.5.3. This release only contains three bug fixes with one of the being rather important for Linux users.

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

...to the Windows installer:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-2.5.3-setup.exe

Here's the full ChangeLog since release 2.5.2:

------------------------------------------------------------
2009-03-07 Moritz Bunkus <moritz@bunkus.org>
* Released v2.5.3.

2009-03-01 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mkvextract, mmg: bug fix: If the environment variables LANG, LC_ALL, LC_MESSAGES contained a locale that was supported by the system but for which mkvtoolnix did not contain a translation (e.g. fr_FR, it_IT, en_AU) then the programs would abort with an error message. Fix for bug 338.
* mkvmerge: bug fix: Appending raw AVC/ES files resulted in segmentation faults. Fix for bug 344.

2009-02-28 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: When mkvmerge was run with the --attachments option to copy only some of the attachments in a Matroska file then any attachment with an ID larger than the first skipped attachment ID was not copied into the new file. Fix for bug 346.
------------------------------------------------------------

Have fun.

fifteen

7th March 2009, 19:56

Can you comment on my post regarding the growing size of raw AVC streams when demux/remuxing multiple times??

http://forum.doom9.org/showthread.php?t=145479

vmrsss

16th March 2009, 15:44

Hey,
I've released mkvtoolnix v2.5.3.
Have fun.

Thanks. Notice that configure still has:

PACKAGE="mkvtoolnix"
VERSION="2.5.2"

Mosu

16th March 2009, 18:20

Thanks. Notice that configure still has:

PACKAGE="mkvtoolnix"
VERSION="2.5.2"

No, it doesn't. Maybe you've gotten the source from my Git repository but forgot to execute autogen.sh? The official 2.5.3 release tarball contains configure with VERSION="2.5.3", but configure is not part of the Git repo.

LeMoi

16th March 2009, 22:53

With latest versions of mkvtoolnix, when i mux files with sub/idx subtitles, last subtitle isn't muxed correctly, picture isn't displayed at all... when i extract the idx/sub from the muxed file, last sub in the track is present but empty.

Mosu

16th March 2009, 23:01

Can you please try to find out since which version this happens? Older versions can be found at http://www.bunkus.org/videotools/mkvtoolnix/win32/

And can you please upload the .sub/.idx to my FTP server? Thanks.

vmrsss

17th March 2009, 01:37

No, it doesn't. Maybe you've gotten the source from my Git repository but forgot to execute autogen.sh? The official 2.5.3 release tarball contains configure with VERSION="2.5.3", but configure is not part of the Git repo.

That was it, thanks. (It's the first time I come across configure out of the repo.)

vmrsss

17th March 2009, 02:04

PS. After running autogen.sh, configure does recognize wxWidgets anymore:

error: #error wxWidgets compiled without Unicode support

Is it a change in 2.5.3 that Unicode support is required? Version 2.5.2 worked without for me.

vmrsss

17th March 2009, 02:32

I would like to add as a complement to my previous message that I have checked out a fresh copy from the*GIT repo, and the build failed as above (#error wxWidgets compiled without Unicode support). I have then dowloaded and unpacked the 2.5.3 tarball, and the build succeeded, producing a seemingly perfect copy of mmg.

b66pak

17th March 2009, 21:50

hi,

first thank you for this great package...

how about timecodes_v1 support in mkvtoolnix?
_

Chumbo

18th March 2009, 03:10

hi,

first thank you for this great package...

how about timecodes_v1 support in mkvtoolnix?
_
It supports the time codes file which can contain this format. If you mean something else, then be more specific.

b66pak

18th March 2009, 18:01

i mean extract timecodes_v1 not only timecodes_v2...
_

LeMoi

19th March 2009, 21:05

Mosu

23rd March 2009, 15:57

Is it a change in 2.5.3 that Unicode support is required?

Yes. I see no gain in supporting non-Unicode enabled wxWidgets builds as every major Linux distribution comes with Unicode enabled wxWidgets.

Mosu

23rd March 2009, 15:58

i mean extract timecodes_v1 not only timecodes_v2...
_

Nope, sorry.

Mosu

23rd March 2009, 16:01

Version 2.3.0 has the bug, 2.2.0 hasn't

Thanks for finding out, but can you please upload the subs somewhere? :)

khagaroth

24th March 2009, 07:08

The new header editor is really nice, saves me a lot of time when changing default tracks, do you plan for it to support tag editing, matroska sorely lacks a usable tag editor.

Mosu

24th March 2009, 11:25

Maybe, maybe not. Other things have higher priority.

Mosu

24th March 2009, 16:43

Hey,

I've released mkvtoolnix v2.6.0. This release contains two new features
(a header editor for existing Matroska files and a Japanese translation)
and a couple of bug fixes dealing with charset and translation issues.

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

...to the Windows installer:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-2.6.0-setup.exe

Some of the binaries are still being built and should be available
within the next two hours.

Here's the full ChangeLog since release 2.5.3:

------------------------------------------------------------
2009-03-24 Moritz Bunkus <moritz@bunkus.org>
* Released v2.6.0.

2009-03-22 Moritz Bunkus <moritz@bunkus.org>
* mmg: new feature: Added a header editor for Matroska files.

2009-03-21 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix: The "simple" chapter extraction mode (OGM style chapter output) outputs strings converted to the system's current charset by default now instead of always converting to UTF-8. This can be overridden with the "--output-charset" command line option. Fix for bug 359.

2009-03-18 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: QuickTime audio tracks will be stored with the CodecID "A_QUICKTIME". The CodecPrivate element contains the full "STSD" element from the QuickTime file (just like V_QUICKTIME). This method is used for all audio tracks which don't have a well-defined storage spec for Matroska (e.g. AAC, AC3, MP2/3 are still stored as A_AC3, A_AAC etc). Hopefully a fix for bugs 354 and 357.
* mkvmerge: bug fix: The CodecPrivate element for QuickTime video tracks like Sorenson Video Codecs contained wrong data. Fix for bug 355.
* all: Added a Japanese translation by Hiroki Taniura (see AUTHORS).

2009-03-17 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed detection of little endian PCM tracks in MOV files. Fix for bug 356.

2009-03-15 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix: The charset for text output was not initialized correctly resulting in garbled display of non-ASCII characters in non-UTF-8 locales.
* all: bug fix: A couple of translated strings were converted from the wrong locale when they were displayed.
* mmg, mkvinfo: The GUIs now require an Unicode-enabled version of wxWidgets.

2009-03-14 Moritz Bunkus <moritz@bunkus.org>
* all: bug fix: The tools use the API call "GetOEMCP()" on Windows instead of "GetACP()". This should make messages output in cmd.exe come out correctly for Windows versions for which cmd.exe uses a different code page than the rest (e.g. on German Windows).

2009-03-08 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: enhancement: If mkvinfo is started in GUI mode on Windows then the console that was started with it will be closed.
* mkvinfo: bug fix: Chapter names and tag elements were recoded to the wrong charset resulting in garbled output. Fix for bug 353.
------------------------------------------------------------

Have fun.

Mosu

DJ Bobo

24th March 2009, 17:33

I don't see a fix for the problem I asked about HERE (http://forum.doom9.org/showthread.php?t=145813) :rolleyes:

Mosu

24th March 2009, 17:38

I don't see a fix for the problem I asked about HERE (http://forum.doom9.org/showthread.php?t=145813) :rolleyes:

mkvmerge copies the complete .idx file except for the lines specifying packets into the CodecPrivate. Therefore all information is available to the filters/codecs. There's nothing mkvmerge can do about it if they're not displayed coming from a .mkv as they are coming from external .idx/.sub files.

madshi

24th March 2009, 20:07

Header editor sounds nice! Can it modify track languages and names without having to rewrite the whole MKV file (provided that enough space is available, of course)?

Mosu

24th March 2009, 20:15

Yes. The header editor allows the user to edit the "segment info" and "track" headers. With it you can change existing values, add values for fields that are not currently present, and remove existing fields as long as they're not mandatory according to the specs.

When the header editor saves its changes to the file it will intelligently pick the best place to store the elements, overwrite any other existing element of the same kind (e.g. Haali's muxer can write the track headers at more than one place) in order to avoid ambiguity, and update the index (meta seek elements) to reflect all changes.

The part that takes quite some time is the initial file scanning phase when you open a file in the header editor. The editor will scan all level 1 elements (those are segment info, track headers, meta seek elements, but also all clusters) for their size and position. While this does not require reading the whole file it still takes a lot of time. This cannot be avoided.

At the moment the header editor also re-scans the file after having saved its changes. This is mainly a safety measure and not strictly neccessary. It will be removed in a future release so that saving the file only takes a second or two.

I should also issue a warning here: Even though I've spent many hours (at least ten) making sure my "save to existing file" algorithm doesn't screw up your files there may still be bugs left in it. So it might be wise to make a backup of important files before editing them, or at least try it on a couple of not so important files first.

Liisachan

24th March 2009, 20:58

Thanks for 2.6.0! I'm going to play with the header editor.
I'm not sure if this is exactly a great idea: The "simple" chapter extraction mode (OGM style chapter output) outputs strings converted to the system's
current charset by default now instead of always converting to UTF-8.
But if that makes other people happy...
And I can use explicit --output-charset anyway.

Mosu

24th March 2009, 21:02

You could also just NOT use the simple chapter format ;) Use the XML chapter format, that's always UTF-8 anyway. Aaaand it offers more features.

madshi

24th March 2009, 22:33

Yes. The header editor allows the user to edit the "segment info" and "track" headers. With it you can change existing values, add values for fields that are not currently present, and remove existing fields as long as they're not mandatory according to the specs.

When the header editor saves its changes to the file it will intelligently pick the best place to store the elements, overwrite any other existing element of the same kind (e.g. Haali's muxer can write the track headers at more than one place) in order to avoid ambiguity, and update the index (meta seek elements) to reflect all changes.

The part that takes quite some time is the initial file scanning phase when you open a file in the header editor. The editor will scan all level 1 elements (those are segment info, track headers, meta seek elements, but also all clusters) for their size and position. While this does not require reading the whole file it still takes a lot of time. This cannot be avoided.

At the moment the header editor also re-scans the file after having saved its changes. This is mainly a safety measure and not strictly neccessary. It will be removed in a future release so that saving the file only takes a second or two.
Thanks, sounds very good! I think this new functionality is really a worthwhile addition.

I'm wondering: Why do you have to read in all the clusters? Is that needed for meta seek updating or what?

Mosu

24th March 2009, 22:48

As I said the scan process locates all level 1 elements. This is a pretty easy process: read the EBML ID, read the element size, seek to the end of the element. But most files use rather small clusters of 2 MB. So mmg reads eight bytes, skips 2 MB, reads eight bytes, skips 2 MB etc. This is not that fast, but not catastrophically slow either. Due to its nature it will be pretty slow when accessing files over a network, I guess.

On my PC this takes roughly a minute for a 1.4 GB file.

I'm wondering: Why do you have to read in all the clusters? Is that needed for meta seek updating or what?

Yes. Matroska's flexible structure allows most header fields to not be present. So when you add a couple of fields mmg might not be able to fit the new headers into the space the old ones occupied. So it looks for the proper place to store them. This can be anywhere in the file with enough "free space".

Another reason is that there's the possibility that there is more than one occurence of the track headers, e.g. Haali's muxer can write multiple instances. Those have to be overwritten in order to not cause ambiguity between updated and not updated headers. As the level 1 elements are not always indexed by meta seek elements mmg has to scan the whole file.

I have an idea or two of how to make this process a bit faster by making certain assumptions as long as there are proper meta seek elements -- but I wanted to get it right first and fast later.

Snowknight26

25th March 2009, 07:43

The installer still likes to take its time when adding/removing the path to the system variables on Vista. Appears (but doesn't) to hang while its doing so.

Mosu

25th March 2009, 11:59

Ok, cannot do anything about that though.

nurbs

25th March 2009, 20:27

I noticed a small bug in mkvmergeGUI. When you use the job queue the "current job" progress bar doesn't show any progress. The bar that shows the finished jobs works fine.

Mosu

25th March 2009, 20:34

Interesting bug. Which OS? Which language do you run mmg with?

turbojet

25th March 2009, 20:55

Is sup support a possibility in the not so distant future?

Mosu

25th March 2009, 21:02

Maybe, don't know yet. Are there specs available? Or source code for demuxers/decoders that can read those files?

turbojet

25th March 2009, 21:22

Unfortunately I don't think there's any specs available and the best information I can get about them is that they contain compressed pictures by RLE (http://en.wikipedia.org/wiki/Run-length_encoding)

DVD sups are used by many authoring applications and can be demuxed by tools like pgcedit and ifoedit. Also just about every text sub/vobsub editor inputs dvd sups. When placed in a vob they can be decoded by many players without the use of an external decoder but I believe DirectVobSub can also decode these.

BD/HDDVD sups are gaining more and more software support. TSMuxer and eac3to demux subtitles to sup only. SupRip, BDSup2Sub, SupRead are sup editors/converters. TSMuxer/TSRemuX/TS4NP use them as input to mux to (m2)ts files. Only players I know of that can decode these are commercial BD players (PowerDVD, Showtime, WinDVD, Arcsoft, etc.) and MPC-HC which I believe uses an updated vsfilter.dll (http://www.xvidvideo.ru/component/option,com_docman/task,doc_download/gid,1423/).

The reason I ask for the sup is so original subtitles can be used without relying on OCR.

Mosu

25th March 2009, 21:30

So no specs, no open source apps? Then I won't be spending time on them soon, sorry.

turbojet

25th March 2009, 21:55

Oh source code you were looking for didn't notice that. Here's some:
PGCDemux (http://download.videohelp.com/jsoto/tools/PgcDemux_1205_src.zip) a dvd sup demuxer
MPC_HC SVN (http://sourceforge.net/scm/?type=svn&group_id=170561) (hd)dvd\bd player\decoder
SubtitleCreator (http://sourceforge.net/project/showfiles.php?group_id=120228&package_id=251117) (hd)dvd sup editor\converter
DVDSubEdit (http://download.videohelp.com/DVDSubEdit/Downloads/DVDSubEditSource1.5.zip) dvd sup editor\converter
TSRemux (http://www.megaupload.com/?d=6G5LPRI4) remuxes BD with sup's

Also info on BD\HDDVD sup (http://exar.ch/suprip/hddvd.php) and some info on dvd sup here (http://dvd.sourceforge.net/spu_notes) and here (http://www.mpeg.org/MPEG/DVD/Book_B/Subpic.html) and here (http://dvd.sourceforge.net/dvdinfo/spu.html)

Mosu

25th March 2009, 22:00

Ah thanks a lot for the links. Now all I'd need would be some sample files. Preferably as TS or EVOs :)

Mosu

25th March 2009, 22:03

Hmm, aren't those the same as vobsubs except that they haven't been extracted from the program streams?

nurbs

25th March 2009, 22:38

Interesting bug. Which OS? Which language do you run mmg with?

Windows XP SP3, german.

Mosu

25th March 2009, 22:41

I'll take a look. Please try changing mmg's language to English and see if the progress works normally then.

turbojet

25th March 2009, 22:43

Your welcome.

BD sup (http://www.sendspace.com/file/e8ohwr)

DVD sup (http://www.sendspace.com/file/9u3dlo)

I don't have any HDDVD sup files here.

If you need the subs inside of a ts container I can upload it in about an hour when blankclip x264 encode finishes.

They may be like vobsub but sup supports things vobsub doesn't like adding a line to a current line without redrawing, different font/color in the same line, fades. VobSub isn't supported by any authoring programs as far as I know, sup is supported by all that I know of except scenarist which uses it's own proprietary scn format or plain bitmaps.

Mosu

25th March 2009, 22:47

Thanks for the samples.

What I'm wondering is if there's a need for the information that VobSub stores in the .idx files -- like palette information etc. Those are gathered from the IFO files if I'm not mistaken. Or is a sup substream enough for proper display?

turbojet

25th March 2009, 23:11

Oh, from what I can tell, dvd vob needs ifo to get it's color palette and stream language. Without the ifo file it relies on the player's color palette and stream languages are unknown.

With BD a standalone (m2)ts file displays subs fine, it also contains stream language (tsmuxer detects) but MPC-HC sets the stream languages as unknown.

Mosu

25th March 2009, 23:27

I noticed a small bug in mkvmergeGUI. When you use the job queue the "current job" progress bar doesn't show any progress. The bar that shows the finished jobs works fine.

Found the problem. The next release will have it fixed.

nurbs

26th March 2009, 13:37

Thank you!

turbojet

26th March 2009, 22:38

Here's a 1080p sup muxed with 1080p blank video in an m2ts (http://www.sendspace.com/file/ki7zsg) if you still needed it.

Sorry it took so long, forgot about it, and thanks for looking at supporting it.

Mosu

26th March 2009, 23:06

Thanks again for providing the files.

HymnToLife

30th March 2009, 07:51

Not sure if this has been reported already, but when I import a MKV file that has a colon in its File/segment title, the colon gets replaced with a "c" in the box under the "Global" tab.

yonta

30th March 2009, 09:14

2009-03-29 Moritz Bunkus <moritz@bunkus.org>

* mkvmerge, mkvetract: new feature: Added support for TrueHD audio
(read from raw streams with or without embedded AC3 frames, MPEG
program streams).

Thank you for adding support for TrueHD streams.

Direct muxing from a evo file fails with Error: common.cpp/safemalloc() called from file src/common/mpeg4_common.cpp, line 1039: malloc() returned NULL for a size of 229756 bytes.
Demuxed streams work fine.

evo sample (http://www.sendspace.com/file/fobcdg)

Mosu

30th March 2009, 09:17

Not sure if this has been reported already, but when I import a MKV file that has a colon in its File/segment title, the colon gets replaced with a "c" in the box under the "Global" tab.

Thanks, should be fixed in http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.6.0-build20090330-101-setup.exe

Kurtnoise

30th March 2009, 09:38

@Mosu: the sample "God Save The Queen" from here (http://samples.mplayerhq.hu/A-codecs/lossless/mlp/) doesn't seem to be recognized as trueHD stream by mkvmerge...

Mosu

30th March 2009, 11:45

MLP is not TrueHD, even though it is almost identical. I've purposefully not added support for MLP.

madshi

30th March 2009, 12:19

Of course you could store MLP content as A_MLP (all else similar to TrueHD muxing)... ;) The purpose of this would be to make demuxed MLP audio tracks (coming from DVD-Audio) seekable. Demuxed MLP audio tracks are not properly seekable in demuxed form due to being VBR.

Not sure how important this is, though. I think TrueHD support is *much* more important!

However, I've heard, the libav guys will very soon have a fully functional MLP encoder. That might increase need for MKV MLP muxing?

Mosu

30th March 2009, 15:56

True. Here's a build with MLP support on top of the TrueHD support and a fix for the loss of the last TrueHD/MLP frame during muxing: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.6.0-build20090330-102-setup.exe

madshi

30th March 2009, 19:57

Thanks! :) Now if only Haali added splitting support for that... :(

Mosu

30th March 2009, 22:54

canuckerfan

2nd April 2009, 00:19

good stuff! any chance for DTS-HD MA?

yonta

2nd April 2009, 04:46

good stuff! any chance for DTS-HD MA?

2008-03-09 Moritz Bunkus <moritz@bunkus.org>

* mkvmerge: new feature: Added support for DTS-HD (both "master audio" and "high resolution").

Mosu

2nd April 2009, 08:25

The only type of DTS audio that's not supported yet that I am aware of is DTS Express. I don't have plans to implement support for it in the near future.

canuckerfan

3rd April 2009, 08:12

2008-03-09 Moritz Bunkus <moritz@bunkus.org>

* mkvmerge: new feature: Added support for DTS-HD (both "master audio" and "high resolution").
wow, that's wicked! do MKV splitters need to also support this, too or will they already work?

Egh

4th April 2009, 04:44

wow, that's wicked! do MKV splitters need to also support this, too or will they already work?

MPCHC internal does. Not sure about haali yet ;)

yonta

6th April 2009, 04:16

Both MPC-HC internal and Haali's splitters output DTS-HD streams.
But, there's no free DTS-HD decoder yet.

The_Keymaker

6th April 2009, 23:56

Please use http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.6.0-build20090330-103-setup.exe for TrueHD/MLP tests -- earlier builds had the sample rate and number of channels swapped for TrueHD/MLP tracks read from EVOs.

I loaded this version of MKVtoolnix (MKVmerge) and muxed the Iron man TrueHD+AC3 audio and Video.

However, when I attempted to play back the file using Zoom Player, only the VIDEO showed up in Zoom Player. An audio stream was not found.

I'm assuming this is an MKVmerge issue and not an eac3to issue since I was able to play the TrueHD+AC3 file fine as a standalone file (i.e., not in a MKV container).

Has anyone had success muxing a TrueHD+AC3 audio file?

NOTE: I have been told that the Haali Media Splitter does not recognize TrueHD tracks. I must use the MPC HC Mpeg splitter!

Maccara

7th April 2009, 07:49

Thank you very much for the new version.

Now, I suggest you fix the Windows installer. If you can't set PATH properly, DO NOT set it at all! Especially since you overwrite the system PATH, not the USER! (wreaks all kinds of interesting havoc)

At least this application informed me properly it screwed up, so I could restore it. :)

(HINT: installer probably parses strings containing "(x64)" etc incorrectly - not the first time I've seen this and probably won't be the last; proper string handling seems next to impossible for installer authors - or they do not realize PATH variable is case insensitive, so it can be Path PATH pATH)

Mosu

7th April 2009, 08:21

NOTE: I have been told that the Haali Media Splitter does not recognize TrueHD tracks.

That's correct so far. Therefore what you're experiencing is most likely not a bug in mkvtoolnix.

Mosu

7th April 2009, 08:22

Now, I suggest you fix the Windows installer. If you can't set PATH properly, DO NOT set it at all!

Please open a bug in my Bugzilla (https://www.bunkus.org/bugzilla/) for this problem.

Maccara

7th April 2009, 09:12

Please open a bug in my Bugzilla (https://www.bunkus.org/bugzilla/) for this problem.

Sorry, public email required for reporting which will be seen by all.

Will have to wait until I have a trash account I can use.

Just remove the damn path settings altogether as 1. they're BROKEN 2. would not work on Vista /w UAC anyway (or so I would gather - can't test atm)

As it is now, it does more harm than good.

Edit: I will report the bug properly when I have the time, but for the meanwhile at least remove it until it can be fixed as the potential to screw up users' system is great at the moment.

Mosu

7th April 2009, 12:56

You'll be happy to know that you're one of two users having reported anything like this at all and that therefore the potential to cause great harm hasn't struck as often as you fear.

Maccara

7th April 2009, 17:14

You'll be happy to know that you're one of two users having reported anything like this at all and that therefore the potential to cause great harm hasn't struck as often as you fear.

That's good to know.

It maybe some specific string/combination I have in the path that triggers this behavior (although, there shouldn't be anything "special" there).

Also, as the specific message from installer was "path was empty", maybe it simply was because my "PATH" was spelled "Path" and some installers are not case insensitive (should be, as they are case insensitive strings) and simply can't find the variable with different casing.

I'll see at some point if I can replicate this issue again and what the conditions seem to be to cause that and open a bug report about it.

Mosu

7th April 2009, 18:02

LeMoi

7th April 2009, 20:42

I tried to install 2.6.0 over a 2.2.0 installation. installation worked fine but not mmg, every time I loaded a fil, i had a code 0 error, file not recoginzed, mkvmerge not found... I checked the path in the options, removed and reinstalled mkvtoolnix, cleaned registry, no way : i can't make version 2.6.0 work, i had to go back du 2.2.0 :s

Mosu

7th April 2009, 21:01

Uninstall v2.2.0, remove the installation folder. Remove the HKEY_LOCAL_MACHINE\Software\mkvmergeGUI and HKEY_CURRENT_USER\Software\mkvmergeGUI registry entries and their children. Install v2.6.0.

The only cases that I know of of mkvmerge always failing is when old DLLs haven't been removed properly.

Maccara

8th April 2009, 09:33

The installer modifies the registry key "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\PATH", so it'd be nice if you could dump that one and send me the resulting .reg file if you can reproduce the problem.
Verified I can repeat the problem and opened a bug report #365 (https://www.bunkus.org/bugzilla/show_bug.cgi?id=365) where I attached registry export (cleaned up to contain only the PATH variable).

herrde

9th April 2009, 13:04

Hi everybody,

everytime I try to load a MKV into the header editor, mmg.exe crashes AFTER scanning the file! I have tried this with many different MKV's.

I am using version 2.6.0 on Vista Ultimate 32bit. Here's Vista's error report:

Problemsignatur:
Problemereignisname: APPCRASH
Anwendungsname: mmg.exe
Anwendungsversion: 2.6.0.0
Anwendungszeitstempel: 49c8ee17
Fehlermodulname: StackHash_7287
Fehlermodulversion: 6.0.6001.18000
Fehlermodulzeitstempel: 4791a7a6
Ausnahmecode: c0000374
Ausnahmeoffset: 000b015d
Betriebsystemversion: 6.0.6001.2.1.0.256.1
Gebietsschema-ID: 1031
Zusatzinformation 1: 7287
Zusatzinformation 2: 688c94a08e5eec5a77e4ba5108a229b8
Zusatzinformation 3: e618
Zusatzinformation 4: 49ff1bd9b2913a34ccbfbe69ebd2a59f

Also, mkvinfo GUI crashes too every time I try to load a MKV!

mkvmerge (GUI) otherwise works completely fine though!

Can you help me?

Best,

Gero

Mosu

9th April 2009, 14:27

everytime I try to load a MKV into the header editor, mmg.exe crashes AFTER scanning the file! I have tried this with many different MKV's.

I am using version 2.6.0 on Vista Ultimate 32bit.

...

Also, mkvinfo GUI crashes too every time I try to load a MKV!

I've received one or two similar reports of crashes on Vista, but I've never succeeded in tracking down a specific problem in one of my tools. My guess so far is that there's an incomtability between wxWidgets and Vista that is triggered somehow.

1. Do the header editor and mkvinfo's GUI crash with each and every Matroska file you're trying to load?
2. If so can you please upload one such file (can be a small one, e.g. create one by splitting) to my FTP server?
3. If not please upload both a file that causes the crashes and a file that doesn't cause a crash.

herrde

9th April 2009, 15:37

1. Do the header editor and mkvinfo's GUI crash with each and every Matroska file you're trying to load?

Yes - I'm not able to open any file!

2. If so can you please upload one such file (can be a small one, e.g. create one by splitting) to my FTP server?

I've just uploaded a small file named "mada2neuer_part-001.mkv" to your server. Like all other MKV's I've tried, it crashes the header editor and mkvinfo (GUI) as well.

Please let me know what you find out!

Thanks a lot!

Best,

Gero

b66pak

9th April 2009, 19:09

hi,

with v2.6.0 i get improper format for timecodes_v2" (tc2mp4 and avi_tc are stopping at the "e+" part!!!):

999583
999625
999708
999791
999875
999958
1.00004e+006
1.00013e+006
1.00021e+006
1.00029e+006
1.00033e+006
1.00038e+006

it should be:

999583
999625
999708
999791
999875
999958
1000042
1000125
1000209
1000292
1000334
1000375

can you repair? (v2.5.3.0 was good)
_

Mosu

9th April 2009, 19:44

The timecode extraction source code has not been changed between 2.5.3 and 2.6.0, so I don't know what's wrong. Please verify that you've really, REALLY tested with mkvextract 2.6.0 and gotten these problems. I did fix timecode extraction with scientific notation quite a while ago, in release 2.5.0 to be precise.

Edit: "mkvextract --version" tells you the version number.

b66pak

9th April 2009, 20:07

version is "mkvextract v2.6.0 ('Kelly watch the Stars') built on Mar 24 2009 15:23:53"

if i use this line:

C:\Program Files\megui\tools\mkvmerge>mkvextract.exe timecodes_v2 test.mkv 1:test.txt
Progress: 100%

it gives the correct result!!!

if i use the GUI (MKVextractGUI.exe) the result is wrong!!!
_

Mosu

9th April 2009, 20:14

Then you have more than one version of mkvextract.exe lying around, and mkvextract GUI is using the old one. Use Windows' search function for locating all mkvextract.exes.

Mosu

10th April 2009, 10:18

Yes - I'm not able to open any file!

Thanks for the upload. Unfortunately I cannot reproduce the problem with any mkvtoolnix version since 2.6.0 on my Vista Business installation -- they all work, both with random files I have and the file you've uploaded.

I'ive compiled a build against wxWidgets v2.8.10 (the other ones were built with v2.8.8), maybe that'll fix your problem. If not then I'm out of ideas for the moment. Here's the build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.6.0-build20090409-111-setup.exe

turbojet

10th April 2009, 11:33

Just out of curiosity how is the sup support coming along?

Feel free to ask if you need anything else from me.

Mosu

10th April 2009, 11:34

Haven't started yet, won't be ready this month, I guess.

turbojet

10th April 2009, 12:23

ok thanks

herrde

10th April 2009, 12:39

I'ive compiled a build against wxWidgets v2.8.10 (the other ones were built with v2.8.8), maybe that'll fix your problem. If not then I'm out of ideas for the moment. Here's the build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.6.0-build20090409-111-setup.exe

Thanks for trying, but this version doesn't work for me either - same situation. Both mkvinfo GUI and the header editor of mkvmerge crash after analyzing the MKV on my Vista Ultimate SP1. I tried running them with Administrator rights and also in Windows XP SP2 compatibility mode, but to no avail.

Please let me know if you come across any solution to this problem. I'd love to use the header editor to change the language tags of streams within a MKV file, and I don't know about any other solution for this task except for the abandoned Matroska Shell Extensions which don't seem to work properly, at least not under Vista.

Thanks again,

Gero

vmrsss

11th April 2009, 20:22

Egh

11th April 2009, 21:32

Hi. I believe one can have an most one previous (and at most one next) segment. Right?

I am thinking of handling a typical situation for TV serials - A: an episode opening, B: the opening titles, B: the show, D: the closing titles, where A and C are per episode, and B and D are always the same. Is there a way to handle whilst keeping only one copy of B and D?

Why not? Also, your description is incorrect (i.e. too narrow).

In the worst but practical case, you have A+B+C+D+E. Where A -- ep introduction, B - episode OP, C - Main Episode, D - episode ED, E - Next ep preview. In this case each file actually contains three matroska segments, i.e. A+C+E. B and D are in separate files, and everything works provided you use Haali Splitter for that.

vmrsss

12th April 2009, 04:26

Why not? Also, your description is incorrect (i.e. too narrow).

In the worst but practical case, you have A+B+C+D+E. Where A -- ep introduction, B - episode OP, C - Main Episode, D - episode ED, E - Next ep preview. In this case each file actually contains three matroska segments, i.e. A+C+E. B and D are in separate files, and everything works provided you use Haali Splitter for that.

and how do you use mkvmerge (or mmg) to mux those? (i'm not on windows, haven't tried Haali Splitter, but VLC seems to understand segments)

b66pak

12th April 2009, 18:47

@Mosu do you plan include a -demuxall option to mkvextract (eventually -demuxallaudio, -demuxallvideo +/- timecodes) like eac3to can do?
_

Mosu

12th April 2009, 18:54

Not really, no.

b66pak

12th April 2009, 19:37

may i ask why? this would be very useful for cli users...
_

Mosu

12th April 2009, 19:45

Because there are lots of other things I'd like to implement, and those are higher on my priority list.

b66pak

12th April 2009, 19:51

it is ok...may be you can queue this feature at the end of the priority list...
_

Egh

12th April 2009, 21:23

and how do you use mkvmerge (or mmg) to mux those? (i'm not on windows, haven't tried Haali Splitter, but VLC seems to understand segments)

Via ordered chapters. They have links to segment Ids. Actually it is much more convenient to implement them now, since we have mkv header editor (kudos to Mosu for that ;P)

Easiest way to learn: obtain what already uses ordered chapters, demux the chapters in XML format and see for yourself.

Mosu

12th April 2009, 21:38

For everyone using the header editor: I advise to use this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.6.0-build20090412-120-setup.exe Older builds (and also release v2.6.0) may produce files that are not as compatible with existing parsers as I'd liked.

vmrsss

12th April 2009, 23:52

Via ordered chapters. They have links to segment Ids. Actually it is much more convenient to implement them now, since we have mkv header editor (kudos to Mosu for that ;P)

Easiest way to learn: obtain what already uses ordered chapters, demux the chapters in XML format and see for yourself.

Thx, will do.

Isochroma

13th April 2009, 04:01

MKVToolnix 2.6.0 (24 March) fails on this MP4 file (http://www.megaupload.com/?d=73DBOR4S). After muxing the file plays in MPC at full speed (system limit) rather than the correct 25 FPS.

However, using Graphedit (Haali Media Splitter 1.9.42.1) the file can be muxed using Haali's Matroska Muxer (directshow, same version) and works fine. The resultant file can then be remuxed using MKVMerge and it also works.

Mosu

13th April 2009, 16:40

Isochroma: The problem is the audio part of the file. In this file each audio block seems to contain more than one AAC frame which mkvmerge cannot deal with as AAC frames are stored headerless in MP4 files. I don't know when if at all I'll get around to fixing this.

TheFluff

14th April 2009, 03:06

Eric B

14th April 2009, 22:49

Inspector.Gadget

15th April 2009, 03:01

Is it or would it be possible to load this file within mkvtoolnix (i.e via mkvmerge GUI) so that these delays are automatically set for the streams?

This is already done for audio automatically in MMG when the delay name is present in the name of the audio file - e.g., after VOB(s)/TS demuxing with DGIndex.

Mosu

15th April 2009, 07:56

1) dvd decrypter generated a "Stream Information.txt" during the rip of a dvd video. This file contains the delay of all streams, particularly the subtitle streams.
Is it or would it be possible to load this file within mkvtoolnix (i.e via mkvmerge GUI) so that these delays are automatically set for the streams?
Edit: probably a bad idea: the delay information is not the delay of the subtitle track, but seems to be simply the timestamp of the first subtitle

Indeed a bad idea, and no, I won't implement this.

2) I see a case "aac is he/sbr" in mkvmerge. Could it be not set automatically by looking at the file?

Not for raw .aac files, no. At least not without decoding the frame, and I don't want to include a complete AAC decoder in mkvtoolnix.

It is possible for containers in which MP4-alike private codec data is stored, e.g. for MP4 and Matroska, but again it is not always possible for others like MPEG program streams.

3) concerning the video, if I do not specify an aspect ratio, will the one from the video track be automatically taken? If yes, would it be possible to display it in the GUI?
Edit: yes, it is better to let it empty. So as said, the textbox could be auto filled in mkvmerge gui.

No. Not everything should be pre-set in the GUI. mkvmerge will already do the "right thing" if you don't modify any options, and extracting the aspect ratio so that mmg could set it would require quite a lot more code that I don't want to write right now. So this won't be changed either.

Mosu

15th April 2009, 09:55

Hey,

I've released mkvtoolnix v2.7.0. This is mostly a bug fix release but also contains support for one of the most-often requested feature: TrueHD/MLP audio tracks.

I recommend everyone to upgrade to v2.7.0, especially if you're using the header editor introduced in v2.6.0.

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

...to the Windows installer:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-2.7.0-setup.exe

Here's the full ChangeLog since release 2.6.0:

------------------------------------------------------------
2009-04-14 Moritz Bunkus <moritz@bunkus.org>
* Released v2.7.0.
* Build requirements changed: mkvtoolnix requires Boost v1.32.0 or later.

2009-04-13 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: mkvmerge will now use SimpleBlock elements instead of normal BlockGroup elements by default.

2009-04-11 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mmg: new feature: Added support for the "forced track" flag. Fix for bug 128.
* mmg: bug fix: The header editor and chapter editor will not write zero bytes anymore if there's not enough space to write an EbmlVoid element when saving to Matroska files.

2009-04-08 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: By default mkvmerge keeps the aspect ratio information in AVC/h.264 video bitstreams now (equivalent to specifying "--engage keep_bitstream_ar_info" in earlier versions). A new option "--engage remove_bitstream_ar_info" is available that restores the previous behaviour.
* mkvmerge: bug fix: Fixed the aspect ratio extraction for AVC/h.264 video by adding three more pre-defined sample aspect ratios. Mkvmerge also only assumes "free aspect ratio" if the aspect ratio type information indicates it and not if the type information is unknown.

2009-04-05 Moritz Bunkus <moritz@bunkus.org>
* mmg: new feature: Added drag & drop support for the header editor (files can be opened by dropping them on the header editor).
* mkvmerge: new feature: Added support for reading the track language from QuickTime/MP4 files. Thanks to Eduard Bloch for the code for unpacking the language string.
* mmg: bug fix: All arguments are shell escaped and quoted instead of only those with spaces in them. Only applies to the menu options "show command line", "save command line to file" and "copy command line to clipboard". Fix for bug 364.

2009-03-30 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mkvextract: new feature: Added support for MLP audio.
* mmg: bug fix: When adding a file with colons in the segment title all colons were replaced with the letter 'c'.

2009-03-29 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge, mkvetract: new feature: Added support for TrueHD audio (read from raw streams with or without embedded AC3 frames, MPEG program streams).

2009-03-25 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: The job manager's status output was garbled if mmg was run with another language as English.
* mmg: bug fix: The progress bar for each individual job in the job dialog wasn't updated if mmg was run with another language as English.
* mmg: bug fix: The timecodes in the job queue editor were off by one month. The "added job on" was additionally off by an amount depending on the user's time zone. Fix for bug 362.

2009-03-24 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The MPEG program stream (VOB/EVO) reader was sometimes reading the timecodes wrong resulting in bad audio/video synchronization. Fix for bug 337.
------------------------------------------------------------

Have fun.

Mosu

Eragon4ever

15th April 2009, 13:35

I just got "Error: 'use_simpleblock' is not a valid hack." and guess this is related to:
2009-04-13 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: mkvmerge will now use SimpleBlock elements instead of normal BlockGroup elements by default.

Disabling "Always use Simple Blocks" in the options fixed it, so you might want to remove this option completely. The new hack is "no_simpleblocks" after all.

Mosu

15th April 2009, 13:40

Yes, that is correct. The option has already been removed from mmg and the next release will not have this problem anymore.

Eric B

15th April 2009, 14:06

thanks for the answer on my previous (bad) ideas.
Yet another question: is is possible to edit the metadata of an mkv file without demuxing/remuxing it, e.g. edit the name of a track?

Mosu

15th April 2009, 14:27

Use mmg's new header editor: "File" -> "Header editor". But make sure you're using v2.7.0 which contains a few but important bug fixes for the editor.

vmrsss

15th April 2009, 14:52

Hello.

My builds of mmg turn out to have a window just about too small, so that the Global Tag input is partially hidden as in the picture below

http://i43.tinypic.com/2l8l20z.jpg

This is not a great problem, of course, as I can resize the window manually when I need it. Yet, is there a simple way to adjust the size once and for all?

Thx

LoRd_MuldeR

15th April 2009, 15:05

Mosu, I just downloaded MKVToolnix 2.7.0 and I had to notice that AntiVir detects some Trojan (TR/Angelus.ZK) (http://img15.imageshack.us/img15/4273/mkvtoolnixfalsepositive.jpg) in the installer.

I am pretty sure that this is yet another "false positive" and that you cannot do anything about it. But you should be prepared for angry people complaining about virus.

I know what I'm talking about. Had this before with my NSIS installers :rolleyes:

Mosu

15th April 2009, 15:11

This is not a great problem, of course, as I can resize the window manually when I need it. Yet, is there a simple way to adjust the size once and for all?

I'm not sure, I'm really no expert on wxWidgets. Maybe.

Mosu

15th April 2009, 15:12

Mosu, I just downloaded MKVToolnix 2.7.0 and I had to notice that AntiVir detects some Trojan (TR/Angelus.ZK) (http://img15.imageshack.us/img15/4273/mkvtoolnixfalsepositive.jpg) in the installer.

I am pretty sure that this is yet another "false positive" and that you cannot do anything about it. But you should be prepared for angry people complaining about virus.

Yeah I know, I'm using Antivir myself and have already seen that message. This is indeed not the first time that anti virus software detects false positives with my NSIS installers either.

Liisachan

15th April 2009, 17:05

I'd actually like it if the files were just zip'ed or 7-zip'ed, without installer. I'll unzip it anyway without using the installer. That's because I experienced a disaster once when I installed mkvtoolnix using its installer; I installed the files into a shared folder called h:\local\bin and the uninstaller deleted everything in that folder.

Btw, that's not my worst experience. I once installed ac3filter into c:\windows\system32 and its freaking uninstaller deleted everything in system32. oh the humanity... I had to reinstall the OS just because this ac3filter. Great. Anyway, the installer is clean according to http://virusscan.jotti.org/

http://ffdshow.faireal.net/shared/mkvtoolnix270.png

Pirks

16th April 2009, 07:37

Mosu, first of all, many thanks for your wonderful MKV toolset! Now, I have one MOV file which I would like to remux to MKV. Here's the link where you can download it:

http://rribsa.bay.livefilestore.com/y1pjPDgUZagNma6KBAhdryteb-LeyvkcWcO3HCOkq1OZmKdZ13klMk6pn-JxWIykRQtuI4HFBNLUFEQX-JiRji19odKAS8naune/P1000153.MOV?download

And this is the error message mkvtoolnix 2.7.0 gave me when I tried to remux it into MKV with default settings:

http://rribsa.bay.livefilestore.com/y1pTEHHygdSvrzKcKrBO2dKBnwYSRjFSizWbUw9qScx16MtAJwsKSUqCqXLiCXhKiplcrkPpmEa5cNAF6bmiCNHksUcmcsgcXkf/mkverror.png

Mosu, could you please look into this? Is there a chance that you add support for these raw audio and jpeg video tracks to 2.8.0?

Mosu

16th April 2009, 08:01

Mosu, could you please look into this? Is there a chance that you add support for these raw audio and jpeg video tracks to 2.8.0?

No, sorry.

Pirks

16th April 2009, 08:22

No, sorry.Why? Just curious. What are the technical obstacles? Or something else?

16th April 2009, 09:03

Regression in 2.7.0 when using --split with over mkv input with flash video in vfr mode: result file didnt seek properly (mpc-hc and smplayer freezes), while source and 2.6.0 output didnt have such problem (instant seeking works in mpc-hc and mplayer)

Source MKV (40473 KB) - http://rapidshare.de/files/46754058/source-mkv.zip.html

Results MKV (56270 KB) - http://rapidshare.com/files/221943656/results-mkv.zip.html

mkvmerge -o test.mkv --display-dimensions 1:480x360 source.mkv --split timecodes:00:03:00,00:06:00

Mosu

16th April 2009, 09:05

I don't consider those two important enough. Unless more people request support for such tracks (and unless they can convince me that they actually use such tracks and don't just want to keep all the content regardless of whether or not they would ever play back such a track) I won't spend the little free time I have on such issues. There are more important parts that I want to work on and that people have requested. Also I don't think that there's any support for such tracks in any player/demuxer, so that would also require work.

Mosu

16th April 2009, 09:07

Regression in 2.7.0 when using --split with over mkv input with flash video in vfr mode: result file didnt seek properly (mpc-hc and smplayer freezes), while source and 2.6.0 output didnt have such problem (instant seeking works in mpc-hc and mplayer)

Please try muxing with 2.7.0 with the additional parameter "--engage no_simpleblocks". Also try remuxing with 2.7.0 without that parameter AND without splitting. Try playing all those files and report back here.

16th April 2009, 10:31

This option resolves the problem, everything works like in 2.6.0 (both mpc/hc and s/mplayer), no regression.

source.mkv splitted succesfully by 2.7.0 with "--engage no_simpleblocks" option

source.mkv remuxed succesfully by 2.7.0 with "--engage no_simpleblocks" option

source.mkv remuxed succesfully by 2.7.0 without "--engage no_simpleblocks" option

Eragon4ever

16th April 2009, 14:19

A bug in the header editor:
I loaded a file, edited the title, saved and then loaded the next file. At this point I couldn't edit anything anymore. The right part of the GUI completly unresponsive, no way to select the text fields anymore. Restart of the header editor fixes this.

vmrsss

16th April 2009, 15:35

is the documentation for --engage available somewhere? From previous messages it sounds like one should use --engage no_simpleblocks when splitting files, and I know absolutely nothing about that. (not to mention questions related to the change with keep_bitstream_ar_info.)

Mosu

16th April 2009, 16:09

The --engage options are not really documented as they should not be used at all (!). That splitting results in unplayable files if "--engage no_simpleblocks" is not used is either a bug in mkvmerge or a bug in the playback chain (splitter, player etc) -- I have not yet figured out which.

You can get a list of available options for --engage with "mkvmerge --engage list" or via mmg's option "Muxing" -> "Add command line options". mmg also shows a short description for each --engage option, but it does not list each and every effect and consequence of the options.

--engage options are meant for developers ( = for me ) and very advanced users. I usually don't give support for problems that result due to the usage of --engage options.

Mosu

16th April 2009, 22:17

Regression in 2.7.0 when using --split with over mkv input with flash video in vfr mode: result file didnt seek properly

This problem has been fixed in the following build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.7.0-build20090416-121-setup.exe

I loaded a file, edited the title, saved and then loaded the next file. At this point I couldn't edit anything anymore.

I'll try to fix this over the weekend.

LeMoi

18th April 2009, 11:12

Mosu

18th April 2009, 11:16

Herrde and I have tracked down this problem to there being several different copies of libebml.dll/libmatroska.dll installed on his computer. Since v2.7.0 mkvtoolnix is compiled against static versions of both libraries, so the problem should be gone for you as well.

18th April 2009, 18:17

Regression in 2.7.0 when using --split with over mkv input with flash video in vfr mode: result file didnt seek properly
This problem has been fixed in the following build: build20090416-121-setup.exe (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.7.0-build20090416-121-setup.exe)
Thanks, I can confirm that output from this build (split without --engange and remux without --engange) works perfectly.

clavelm

27th April 2009, 23:11

Dismiss.

fingershop

29th April 2009, 01:00

Mkvtools are great, I use them all the time!

One task that I seem to do a lot of is converting video files (mkv, avi, mp4, vob, etc) from 25 fps to 23.976. After some audio transcoding, I currently I have to use extra steps in this process because MMG won't let me change the framerate when I remux directly from the container source files.

This means I have to first demux the video track, and then mmg will let me change the framerate. This extra step has become very cumbersome, as the HD video tracks are quite large, and it takes almost twice as long, and uses twice the space, with all this extra muxing.

When I'm muxing with mmg I'd really like to be able to set the framerate for any type of video source files, and not be limited to doing this with only elemental streams.

Frequently my biggest use of mmg is not in packaging media content, but rather its in re-packaging it. I'd like mmg to make it easier to do this.

Thanks

SquallMX

30th April 2009, 02:35

Hi, i found something wrong with MKVMerge after updating to 2.7.0 (MeGui update), when muxing a RAW H264 the output is corrupted in some frames:

RAW H264:
http://www.imagechile.net/img/img7_1241055245a.png

MKV H264:
http://www.imagechile.net/img/img7_1241055295s.png

Source is Bolt Region A Bluray H.264 24 Mbps, thank you!

Mosu

30th April 2009, 08:17

Hi, i found something wrong with MKVMerge after updating to 2.7.0 (MeGui update), when muxing a RAW H264 the output is corrupted in some frames:

Did you enable splitting and is this from the second or one of the following file(s)? If so this is a known bug that has been fixed in a pre-release.

If not then you should try finding out if this happens with older versions, too. All older mkvtoolnix releases are available from http://www.bunkus.org/videotools/mkvtoolnix/win32/

Mosu

30th April 2009, 08:21

When I'm muxing with mmg I'd really like to be able to set the framerate for any type of video source files, and not be limited to doing this with only elemental streams.

I will probably implement this; probably not for the next release but the one after. In the meantime you can use a workaround by using a timecode file. The v1 timecode file format allows you to specify a default frame rate and ranges of frames with frame rates different from the default frame rate. As you want a fixed frame rate such ranges are not needed, and the timecode file in question would only contain these two lines:

# timecode format v1
assume 23.976

You could name it 23976.txt or something like that and re-use it each time you need to change the frame rate in this way.

fingershop

30th April 2009, 09:12

Thanks, I'll watch for the release that includes this.

I just tried the workaround and it works great!

That really helps a lot, thanks again.

SquallMX

30th April 2009, 20:50

Did you enable splitting and is this from the second or one of the following file(s)? If so this is a known bug that has been fixed in a pre-release.

If not then you should try finding out if this happens with older versions, too. All older mkvtoolnix releases are available from http://www.bunkus.org/videotools/mkvtoolnix/win32/

Just one single file, i try using the old version 2.1.0, the problem still appears:

http://rapidshare.com/files/227616527/Sample.rar

RAW and M2TS (using TSMuxer) are fine.

:thanks:

Chumbo

3rd May 2009, 20:20

A request Mosu, can you add a 60000/1001 option?
I was about to ask for the same thing, when I found this. I second this request please as an FPS option under the Format specific options tab. Thank you.

Keiyakusha

3rd May 2009, 20:35

I want to request FPS option for any type of video source too...

Mosu

3rd May 2009, 21:02

Just one single file, i try using the old version 2.1.0, the problem still appears:

Ok, then I cannot help you at the moment. Sorry.

Mosu

3rd May 2009, 21:03

I was about to ask for the same thing, when I found this. I second this request please as an FPS option under the Format specific options tab. Thank you.

Will do.

I want to request FPS option for any type of video source too...

That as well.

vmrsss

8th May 2009, 16:19

Hi there.

My architecture is MacOSX/Leopard, which does not seem to support FADVICE. I believe that this commit

> commit a7a753c75af8bfeb479e429cdc31de6b28e6ebc0
> Author: Moritz Bunkus <moritz@bunkus.org>
> Date: Thu May 7 19:11:17 2009 +0200
>
> Disable posix_fadvise for files that are opened multiple times at the same time.

broke it: building fails with

> CXX src/merge/cluster_helper.cpp
> In file included from src/merge/cluster_helper.h:25,
> from src/merge/cluster_helper.cpp:27:
> src/common/mm_io.h:151: error: 'file_id_t' does not name a type
> make: *** [src/merge/cluster_helper.o] Error 1

Which is not surprising, as it appears that the definition of file_id_t only appears under an #if HAVE_POSIX_FADVISE.

Related problems occurs in mm_io.cpp, where

mm_file_io_c::setup_fadvise(...)

is used outside the scope of #if HAVE_POSIX_FADVISE.

Hope this is easy to fix, is it?

Mosu

8th May 2009, 17:01

My architecture is MacOSX/Leopard, which does not seem to support FADVICE. I believe that this commit

> commit a7a753c75af8bfeb479e429cdc31de6b28e6ebc0
> Author: Moritz Bunkus <moritz@bunkus.org>
> Date: Thu May 7 19:11:17 2009 +0200
>
> Disable posix_fadvise for files that are opened multiple times at the same time.

broke it:

Thanks for noticing. I've fixed the issue.

mbcd

8th May 2009, 23:34

@SquallMX:

Here I cant even play your sample. The sample seems to be damaged already.

If I found a player who plays it, it stops playing exactly at scenechange to your posted picture.

My own encoded raw-x264-files are played back fine.

turbojet

9th May 2009, 07:09

Any plans for m2ts input support?

Mosu

9th May 2009, 10:28

Not in the near future.

turbojet

9th May 2009, 15:34

OK is sup support still on the table?

Mosu

9th May 2009, 15:39

Yes, but not in the near future.

roozhou

9th May 2009, 15:42

Why mkvmerge does not support asf/mpeg-ts/mpeg-ps?

Mosu

9th May 2009, 15:57

mkvmerge supports MPEG program streams (MPEG PS) but not ASF/MPEG transport streams. ASF and its close cousin WMV have never been priorities of mine, and there was a time when Microsoft was coming after people implementing support for those containers. Missing support for MPEG transport streams is a matter of available time or the lack thereof and -- due to the lack of ample amounts of free time -- priorities.

roozhou

9th May 2009, 16:09

The_Keymaker

9th May 2009, 16:10

I've used MKVmerge to mux The Matrix reloaded with TrueHD Audio successfully. However as I learned sometime ago, Haali media splitter does not support TrueHD. Does any know of a splitter or source filter i can use to play back this file?

Thanks!

Mosu

9th May 2009, 16:12

And what about importing directly from DVD IFOs? So I don't need to demux ac3/dts before remuxing encoded video into mkv.

IFO files are not read, but VOB and EVO files are as they are MPEG program stream files.

roozhou

9th May 2009, 16:14

IFO files are not read, but VOB and EVO files are as they are MPEG program stream files.

A dvd title may contain several VOBs. Do i have to join them?

Mosu

9th May 2009, 16:18

No, you can use mkvmerge's/mmg's append feature.

Mosu

9th May 2009, 16:32

Hey,

I've released mkvtoolnix v2.8.0. This release contains a lot of smaller and larger bug fixes and a new translation to simplified Chinese.

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

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

All binaries that I provide myself have already been built and uploaded.

Here's the full ChangeLog since release 2.7.0:

------------------------------------------------------------
2009-05-09 Moritz Bunkus <moritz@bunkus.org>
* Released v2.8.0.

2009-05-07 Moritz Bunkus <moritz@bunkus.org>
* all: Added a translation to Chinese (simplified) by Dean Lee (see AUTHORS).
* mkvmerge: enhancement: Added support for handling AC3 audio in MP4 files with the FourCC "sac3" (as created by e.g. Nero Recode v3/4). Fix for bug 384.
* mkvmerge, mmg: enhancement: Made mmg's "FPS" input field available for all video tracks. mkvmerge's corresponding option "--default-duration" now not only modifies the track header field but affects the frame timecodes as well.

2009-05-06 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The VobSub reader was dropping the very last MPEG packet possibly resulting in the very last subtitle entry being garbled or discarded completely. Patch by Todd Schmuland.

2009-05-03 Moritz Bunkus <moritz@bunkus.org>
* mmg: enhancement: Added "60000/1001" as a pre-defined option to the "FPS" drop-down box.

2009-04-29 Moritz Bunkus <moritz@bunkus.org>
* mmg (header editor): bug fix: The header editor controls on the right stopped responding after the second file had been loaded or the "reload file" feature had been used. Fix for bug 372.

2009-04-27 Moritz Bunkus <moritz@bunkus.org>
* mmg: new feature: Added an option for clearing all inputs after a successful muxing run.

2009-04-25 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Made the AAC detection code stricter in what it accepts. This results in fewer mis-detections. Fix for bugs 373 and 374.

2009-04-16 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Splitting without the option "--engage no_simpleblocks" resulted in broken files: all frames were marked as B frames. Fix for bug 371.
* mkvinfo: bug fix: Timecodes of SimpleBlock elements that were output formatted in summary mode were too small by a factor of 1000000.

2009-04-15 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The duration of subtitle frames was overwritten with the difference between the next frame's timecode and the current frame's timecode if a timecode file was used for that track. Fix for bug 286.
* mmg: bug fix: Removed the option "always use simple blocks" from the preferences dialog as this option was already removed from mkvmerge. Fix for bug 370.
------------------------------------------------------------

Have fun :)

roozhou

9th May 2009, 16:33

No, you can use mkvmerge's/mmg's append feature.

And another feature request: cutting mkv's.

Currently If I need to cut a clip from xx:xx:xx to yy:yy:yy, I have to use splitting and mkvmerge produces 3 clips including two I don't need.

Mosu

9th May 2009, 16:36

And another feature request: cutting mkv's.

Not in the near future.

roozhou

9th May 2009, 16:42

Not in the near future.

:eek:Is there a way to disable the 2 unnecesary clips?

Mosu

9th May 2009, 16:51

No, there is none.

Keiyakusha

9th May 2009, 16:51

Hey,

I've released mkvtoolnix v2.8.0. This release contains a lot of smaller and larger bug fixes and a new translation to simplified Chinese.
Thanks! :)

turbojet

9th May 2009, 16:59

Not in the near future.

Summer vacation or low priority?

Mosu

9th May 2009, 17:23

Due to an oversight the original installer and 7zip archive did not contain the Chinese translation. Additionally the 7zip contained a wrong directory structure for all translations. Both issues have been fixed by replacing the existing installer and 7zip. If you've downloaded one of the two files before 18:25 CET then I suggest you re-download them.

Other than that the packages have not been changed.

Mosu

9th May 2009, 17:24

Summer vacation or low priority?

Very little free time and therefore low priority. No vacation for me this summer either.

cyberbeing

9th May 2009, 17:35

I'm getting a forbidden error on the 2.8.0 win32 version.

Mosu

9th May 2009, 17:46

Fixed, try again.

cyberbeing

9th May 2009, 17:51

Fixed, try again.

Working now, thanks.

Liisachan

9th May 2009, 18:11

Thank you for releasing the windows binary also in .7z.

However if it's too much bother, or can cause confusion (like accidentally missing files), I think you can just release the installer exe only as you did before, since the archiver 7-zip can uncompress ("open") the installer without running it anyway.

Mosu

9th May 2009, 18:34

It's no bother. I have an automated script that creates both the installer and the 7z archive. I just forgot to fix a few file names; this is done now, so it's no more effort.

9th May 2009, 18:37

* mkvmerge, mmg: enhancement: Made mmg's "FPS" input field available for all video tracks. mkvmerge's corresponding option "--default-duration" now not only modifies the track header field but affects the frame timecodes as well.

Wow, I was just about to add that suggestion :) I have found that my files was actually not VFR, so I can rebuild them with that option for smoother playback.

So I already downloaded 2.8.0 and tested this feature, works perfectly! Even while input files was marked VFR, after rebuild I have no sync problems.

Liisachan

10th May 2009, 18:12

This is not that important, and this might be for me only,
but the error handling is not graceful. The whole MMG crashes for me with this message:
"Microsoft Visual C++ Runtime Library, Runtime Error! This application has requested the Runtime to terminate it in an unusual way." if Header editor tries to oepn an MKV file that has been already opened for writing exclusively, when apparently you get an abnormal termination somewhere in header_editor_frame_c::open_file.

I can't debug wxWidgets, but from reading the code, my first impression is that this thing in kax_analyzer_c::kax_analyzer_c should be able to handle the above situation, because it says it catches any exception:

try {
file = new mm_file_io_c(file_name.c_str(), MODE_WRITE);
} catch (...)

If the above 'new' fails, the error should be handled gracefully with the message "Could not open the file". So the problem seems to be before that. It might be that kax_analyzer_c::probe called before that to see if the file is MKV, though it only needs the read access, can't handle an MKV file that is not writable. (Just a guess.)

Originally I noticed this problem when I tried to open MKV w/ Header editor while uploding it to somewhere using FileZilla. FileZilla seems to lock the file while it's uploading it so that anyone else can't modify it (which makes sense). And then I can repro the problem in this minimal condition:

FILE * fp = fopen("G:\\aa.mkv","ab");
MessageBox(0,L"",0,0);// MMG abnormal-terminates if Header editor tries to open aa.mkv here
fclose(fp);

Edit:
But then again, kax_analyzer_c::kax_analyzer_c re-throws the exception. When new kax_analyzer_c fails, does anyone catch that exception re-thrown properly? That's another question.

Mosu

10th May 2009, 23:04

This is not that important, and this might be for me only,
but the error handling is not graceful. The whole MMG crashes for me with this message:

Thanks for the analysis. I've fixed the issue in build 126 available at http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/ .

Liisachan

11th May 2009, 14:45

fixed in mkvtoolnix-unicode-2.8.0-build20090510-126.7z, confirmed. Ty☺

MADAJ

12th May 2009, 13:32

hi, when I import a video source, I get this message.

http://img11.imageshack.us/img11/8864/imagekar.jpg

anything wrong?

Mosu

12th May 2009, 14:35

By now several people have reported the very same problem. However I cannot repreoduce this yet, so I don't know where the problem lies.

Which Windows version are you using (including its native language, e.g. "Windows XP SP3 German")?

Mosu

12th May 2009, 20:52

I need some more information from you. Please do the following:

1. Download and install mkvtoolnix v2.8.0.
2. Start mkvmerge GUI.
3. Open the "preferences" dialog via "File" -> "Preferences".
4. Make sure that the checkbox at the bottom labeled "Show mmg's debug window" is enabled and close the preferences dialog. A new small window should appear; it is labeled "mmg debug output" and hould already contain a couple of lines.
5. Try adding a file with the "add" button as you did last time. The action should fail, but some more lines should appear in the debug window.
6. Dismiss the error dialog that file identification has failed, go to the debug window and save its contents into a file via "Log" -> "Save".
7. Send me that file to moritz@bunkus.org or upload it somewhere.

Thanks.

MADAJ

12th May 2009, 21:17

Hi, I am running Win XP SP3 (English)

http://www.zshare.net/download/59931524d49ddde4/ the log

thanks

Mosu

12th May 2009, 22:40

Thanks, that helped. I'll fix this until the weekend.

Keiyakusha

13th May 2009, 01:23

Mosu
Little bugreport:
If I Start mkvmerge GUI -> Start Header Editor -> Change/add/delete some UID -> save file -- then I can't change/add/delete any UID again and I must restart Header editor.

Little suggestion:
Maybe it will be good to have a small button for generating random UID if we want to change/add one.

EDIT: now, after few UID editings in one file, I have this error:
http://www.petaimg.com/u447/11013.05.png

Mosu

13th May 2009, 07:47

Mosu
Little bugreport:
If I Start mkvmerge GUI -> Start Header Editor -> Change/add/delete some UID -> save file -- then I can't change/add/delete any UID again and I must restart Header editor.

That was a known error in v2.7.0. Please upgrade to v2.8.0.

Little suggestion:
Maybe it will be good to have a small button for generating random UID if we want to change/add one.

Good idea.

EDIT: now, after few UID editings in one file, I have this error:
http://www.petaimg.com/u447/11013.05.png

If you enter invalid data (e.g. if you enter text instead of a number for a header field that expects a number) then you get this message. For UIDs there are actually more rules:

1. An UID must be 128 bits long. The input field shows hex digits (0-9, A-F). Each hex digit represents 8 bits, therefore you have to enter exactly 16 hex digits.
2. I'm not quite sure about the formats that are recognized, but I think you can either prefix hex digits with "0x" or leave it; you can use spaces between hex digit pairs, but not between single digits -- but I may be wrong there; it could be that I've already made the parser less strict.

TheFluff

13th May 2009, 12:50

I found a "bug" the other day while experimenting with a semi-automated split-and-merge script I was writing, although I guess it's less a bug than it is a "don't do that".
Anyway, if you try to use mkvmerge to split at timecode 00:00:00.000, it will happily accept the timecode and sure enough it'll generate two splitted files. The first one turns out to be about 10kB and can't be read by mkvmerge (says "failed to read the headers"). It does appear to contain _something_ but I'm not man enough to figure out what.

Keiyakusha

13th May 2009, 14:58

That was a known error in v2.7.0. Please upgrade to v2.8.0.

Oops, you right. I reinstalled the latest 2.8.0 and it works fine. First time I installed it to the MeGui/tools directory, but some files was not replaced.

If you enter invalid data (e.g. if you enter text instead of a number for a header field that expects a number) then you get this message. For UIDs there are actually more rules:
Well, maybe I made some typo when entering UDI and not noticed this.

Sorry about that. Next time I will recheck a few times more before posting.

Mosu

13th May 2009, 15:51

Mosu

13th May 2009, 15:52

Oops, you right. I reinstalled the latest 2.8.0 and it works fine. First time I installed it to the MeGui/tools directory, but some files was not replaced.

Ok :)

Well, maybe I made some typo when entering UDI and not noticed this.

Sorry about that. Next time I will recheck a few times more before posting.

No problem at all; I know that the error message is very generic and not helpful if the user doesn't know all the details of the Matroska header structure. I will likely improve the error messages in the future.

Mosu

13th May 2009, 18:31

hi, when I import a video source, I get this message.

http://img11.imageshack.us/img11/8864/imagekar.jpg

This problem should be fixed in builds 128 and later available from http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/

Snowknight26

14th May 2009, 03:13

When you add a file twice and you remove the second file, the Remove all button stays disabled.

Mosu

14th May 2009, 08:33

When you add a file twice and you remove the second file, the Remove all button stays disabled.

This problem should be fixed in builds 129 and later available from http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/

MADAJ

14th May 2009, 22:50

This problem should be fixed in builds 128 and later available from http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/

thanks a lot :D

Snowknight26

17th May 2009, 05:44

Any word on FLAC parsing showing 100% twice or is that a non-issue?

Mosu

17th May 2009, 09:19

I don't consider that important, therefore I will or will not fix it. It is only a visual glitch.

vwpassion

17th May 2009, 23:49

I noticed Vobsubs get compressed when muxing them into the mkv, does image quality get degraded as well, or how does the compression work?

Mosu

18th May 2009, 07:27

Extra track compression inside Matroska files is done with lossless compressors. The available choices are zlib (the algorithm behind "gzip"; good compromise between speed and compression ratio), bzlib (the algorithm behind "bzip2"; slow but very good compression ratio) and lzo v1 or v2 (very fast but poorer compression ratio). Of those three only the zlib algorithm is widely supported by playback applications; therefore mkvmerge/mmg default to zlib.

vwpassion

18th May 2009, 10:51

Great, thanks.

Mosu

22nd May 2009, 18:18

Hey,

I've released mkvtoolnix v2.9.0. New features include support for chapters in MP4 files, a translation to Chinese Traditional and support for MPEG-1/-2 video in AVI files. Improvements were made to the MPEG program stream and VobSub handling code. Fixed bugs include several segfaults, crashes in the header editor and mmg always reporting that adding files has failed with a return code of 1 on certain Windows systems. Audio/video synchronization for the native MPEG-4 storage mode has been fixed.

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

...to the Windows installer:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-2.9.0-setup.exe

The binaries I provide myself have all been built and uploaded already.

Here's the full ChangeLog since release 2.8.0:

------------------------------------------------------------
2009-05-22 Moritz Bunkus <moritz@bunkus.org>
* Released v2.9.0.

2009-05-17 Moritz Bunkus <moritz@bunkus.org>
* all: Added a translation to Traditional Chinese by Dean Lee (see AUTHORS).
* mkvmerge: bug fix: mkvmerge was not handling dropped frames well when converting from VfW-mode MPEG-4 part 2 to native mode MPEG-4 part 2 (with '--engage native_mpeg4'). This resulted in timecodes being to low which in turn resulted in the loss of audio/video synchronization. Fix for bug 236.

2009-05-16 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix: The modes 'chapters', 'cuesheet' and 'tags' did not honor the '--redirect-output' option and where always writing to the standard output.
* mkvmerge: new feature: Added a hack ('vobsub_subpic_stop_cmds') that causes mkvmerge to add 'stop display' commands to VobSub subtitle packets that do not have a duration field. Patch by Todd Schmuland (see AUTHORS).

2009-05-15 Moritz Bunkus <moritz@bunkus.org>
* mmg: enhancement: Changed how mmg sets the output file name automatically if the option is enabled. If the user adds more than one file then the output file name is set each time a file is added and not only when the first one is unless the user has changed the output file name manually. Fix for bug 229.

2009-05-14 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: Improved support for QuickTime audio tracks with version 2 of the STSD sound descriptor.
* mmg: bug fix: The "remove all" button was sometimes disabled even though there were still files left to be removed.
* mkvmerge: enhancement: The MPEG program stream reader will now detect invalid padding packets and skip only to the next 2048 byte packet boundary instead of skipping several good packets. Patch by Todd Schmuland (see AUTHORS).
* mmg: enhancement: The "no chapters" checkbox can now be used for QuickTime/MP4 files and OGM files as well.
* mkvmerge: enhancement: The OGM reader will only print the warning that no chapter charset has been set by the user if the title or the chapter information contained in the OGM file is actually used and not overwritten with '--title ...' or '--no-chapters'.

2009-05-13 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix: The VobSub extraction was made more compatible with most applications. Fix for bug 245. Patch by Todd Schmuland (see AUTHORS).
* mkvmerge: bug fix: Fixed support for Windows systems that use code pages that are not supported by the iconv library (e.g. code page 720). mkvmerge was exiting with warnings causing mmg to report that file identification had failed. Fix for bug 376.

2009-05-12 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Added support for handling MPEG-1/-2 video in AVI files. Fix for bug 388.

2009-05-11 Moritz Bunkus <moritz@bunkus.org>
* all: bug fix: Global variables are deconstructed in a pre-defined way no longer causing segfaults when the programs are about to exit.
* mkvmerge: enhancement: Implemented small speedups for some common memory operation (affects e.g. the MPEG program stream parser).
* mkvmerge: bug fix: Fixed potential and actual segmentation faults occuring when appending VC-1 video tracks, Dirac video tracks and DTS audio tracks.

2009-05-10 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: The header and chapter editors will no longer crash the application if the user wants to open a file that's locked by another process and show an error message instead.
* mkvmerge: enhancement: Invalid VobSub packets whose internal SPU length field differs from its actual length are patched so that the SPU length field matches the actual length. This fixes playback issues with several players and filters. Fix for bug 383.
* mkvmerge: new feature: Added support for reading chapters from MP4 files. Fix for bug 385.
------------------------------------------------------------

Have fun.