mkvtoolnix 4.1.1 released

[Mosu]

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]

Nice, thanks for hard work

[HeadBangeR77]

That's good news :) Much appreciated!

[buzzqw]

that's awesome ! thanks !!!

BHH

[Sharktooth]

linux version works perfectly, thanks ;)

[LeMoi]

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

[Eragon4ever]

* 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]

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]

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]

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

[guada2]

great work Mosu.
Bye ;)

[madshi]

The new version is much appreciated!

:thanks:

[Isochroma]

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]

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]

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]

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]

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]

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

[Eragon4ever]

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]

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]

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]

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]

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]

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]

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.

Confirmed. I have such files, too.

[Mosu]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

This update fixed my BBC-HD H.264 MBAFF also, i set it to nal size 3 as the warning showed me, great work.

[madshi]

:) 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]

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]

Thanks Mosu.

[yonta]

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

problem solved! muxed avc es with nalu set to 3 and it plays fine!
Thank you.

[Mosu]

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]

@Mosu guess i read your mind :p

Indeed you do :) Thanks for the samples.

[Mosu]

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]

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]

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]

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]

@Mosu
Thank You ! Great Work !

[madshi]

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]

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]

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]

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

[madshi]

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]

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]

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]

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.

[Haali]

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]

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]

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]

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]

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]

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]

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]

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]

@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]

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

[madshi]

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]

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

[LeMoi]

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]

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]

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]

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

Upload, please :)

[Yong]

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]

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]

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]

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]

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]

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]

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]

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]

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]

@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]

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]

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]

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]

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]

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]

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]

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

[Okraml]

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]

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]

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]

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?

[Eragon4ever]

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]

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]

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]

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.

Yeah, a sample file would be nice. Maybe it's time to fix native MPEG4 mode for good.

[Eragon4ever]

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]

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]

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]

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]

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]

@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]

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]

@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!!


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

[Mosu]

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]

@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]

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]

Ok, thanks... :)

[Jaxel]

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]

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]

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

[Jaxel]

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]

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]

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]

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]

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]

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]

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]

Same here...

[Mosu]

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]

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

[madshi]

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

[madshi]

@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]

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

[har-vas]

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]

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

[Mosu]

What is h.264 MBAFF?

[ExarKun634]

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]

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]

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]

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

[madshi]

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]

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]

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]

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]

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]

Thanks!!

[bob0r]

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]

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]

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]

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]

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]

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]

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]

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

[madshi]

@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]

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]

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]

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]

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]

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]

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?

[Mosu]

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]

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]

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]

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]

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]

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

[Henrikx]

THX Mosu !!!

[Mosu]

(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]

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]

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]

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]

* 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]

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

[madshi]

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]

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]

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

[Mosu]

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

[madshi]

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]

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]

It has H.264 in stream 0xe2.

[Gusar]

Not even mplayer can play that file.

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

[Mosu]

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

[DeepBeepMeep]

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]

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]

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]

* 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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

@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]

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]

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]

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

[Eragon4ever]

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

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

[Mosu]

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

[Henrikx]

:thanks: Mosu

[DeepBeepMeep]

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]

* 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]

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]

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]

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]

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

[akupenguin]

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]

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]

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

[bob0r]

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

[issa]

Mosu,

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

[Mosu]

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]

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]

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

[aabxx]

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]

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]

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]

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]

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.

[zgx]

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]

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?
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.

[zgx]

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]

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]

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]

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]

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?

No.

If not, can you make it available in the next release?

No, sorry.

[issa]

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]

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]

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]

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]

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.

Thanks, I forgot the basic way...

:stupid:

[LeMoi]

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

[Rectal Prolapse]

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]

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]

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]

Thanks Mosu, MKVMergeGUI recognized it!

[Okraml]

@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]

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

[DeepBeepMeep]

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]

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]

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]

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

[Mosu]

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]

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]

No, there isn't.

[bob0r]

@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]

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

[LeMoi]

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

[Mosu]

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]

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]

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

--display-dimensions <track>:1024x576

[honai]

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]

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

[madshi]

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

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