mkvtoolnix 4.1.1 released

[Mosu]

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

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

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

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

[Isochroma]

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

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

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

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

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

[Mosu]

Way too much work, Isochroma, sorry.

[Isochroma]

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

[Mosu]

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

[Mosu]

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

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

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

[madshi]

I've a question about h264 support:

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

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

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

Thanks!

[Mosu]

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

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

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

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

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

[madshi]

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

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

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

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

[delacroixp]

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

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

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

A default setting is all good.


:):D:eek:
Pascal


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

[bob0r]

@Mosu

GREAT GREAT GREEEAT WORK!

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

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

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

[Mosu]

Ah ok. Thanks!

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

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

[madshi]

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

[Mosu]

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

[madshi]

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

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

[delacroixp]

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

VOB files with resetted timecodes in the middle of the file were probably originally two separate VOB files which were just joined. If you search through the internet about how to join VOB files, some people claim you just need to join the binary files without any further changes. And funnily many splitters seem to cope with such joined VOB files quite well. But it's probably technically incorrect to join VOB files that way.
I often use copy /b *.* filename.VOB though it's probably a little archaic given modern file specifications...


:):D:eek:
Pascal

[bob0r]

@Mosu

I have some good news!

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

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

Good job!

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

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

[delacroixp]

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

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

:):D:eek:
Pascal

[DreckSoft]

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

[bob0r]

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

[CruNcher]

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

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

[DreckSoft]

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

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

[KoD]

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

[Mosu]

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

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

[DreckSoft]

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

[CruNcher]

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

[Mosu]

Cruncher: Read my signature :D

[Mosu]

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

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

[CruNcher]

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

Mosu any idea what's wrong ?

[Mosu]

No, sorry.

[Isochroma]

I found a bug!

When I put a shortcut to MKVMergeGUI into the sendto folder, and right-click an mkv file, select send to > mkvmerge gui, the process starts up but never shows a window, and uses 100% of the cpu.

I figured it would be handy to just send files to it (same as 'open with'), it should work like dropping them on an empty mkvmergegui, right?

xp pro sp2

[DeepBeepMeep]

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

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

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

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

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

[delacroixp]

I've been encoding a few seminars from Dr Kent Hovind's 'Creation Science Evangelism' for some christian friends...

The Intro is fine but the main feature needs cropping...
I've encoded both pieces at 640x480 but they have different signalling... the main feature is actually 640x486 DAR.


:):D:eek:
Pascal

[LeMoi]

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

[Dr.Khron]

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

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

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

[LeMoi]

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

[Neo Fagin]

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

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

[Mosu]

I've been encoding a few seminars from Dr Kent Hovind's 'Creation Science Evangelism' for some christian friends...

The Intro is fine but the main feature needs cropping...
I've encoded both pieces at 640x480 but they have different signalling... the main feature is actually 640x486 DAR.

Matroska does support changing of private codec data in the middle of the stream, but this feature is not widely supported (if at all, Haali's splitter might be the only app supporting this at the moment).

However, Matroska's header fields may NOT change mid stream. Therefore the answer is more likely "no".

[Mosu]

I found a bug!

When I put a shortcut to MKVMergeGUI into the sendto folder, and right-click an mkv file, select send to > mkvmerge gui, the process starts up but never shows a window, and uses 100% of the cpu.

I figured it would be handy to just send files to it (same as 'open with'), it should work like dropping them on an empty mkvmergegui, right?

xp pro sp2

This is both a bug and a feature request. When you put mmg into the "Send to" folder then it is executed with the filename as its argument. At the moment mmg only supports reading its saved configuration files this way (the ".mmg" extension is mapped to running mmg). That mmg uses 100% CPU is the bug, that you cannot add files this way is the feature request ;)

I've added this to my Bugzilla (https://www.bunkus.org/bugzilla/show_bug.cgi?id=243).

[Mosu]

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

Definitely a bug. I've downloaded the sample file and opened a bug (https://www.bunkus.org/bugzilla/show_bug.cgi?id=244) for it.

[Mosu]

A small feature request (dunno if it's already been requested) - can there be a checkbox in options to enable quiet mode (-q) without error reporting?

Hmm, I don't want to add this. If mkvmerge spills out warnings then there are issues the user has to be aware of. Warnings are nothing to laugh at, and suppressing them by default seems like a recipe for grief.

When muxing DTS created with Surcode, if the DTS has padding, mkvmerge strips the padding which is fine, however it produces thousands of error messages and the process stalls waiting for the console / GUI to catch up to display them, causing it to take literally half a day to mux a DTS track. This also occurs with AC3 and other tracks which have padding in them.

I've changed something in the MPEG reader code lately, but I think I haven't built a new Windows build with those changes. Let me do this now. (goes away for a minute) Here you go. Please download this build and test against the files that produce those warnings:
http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.0.2-build20070530-1.rar

[Neo Fagin]

Hmm, I don't want to add this. If mkvmerge spills out warnings then there are issues the user has to be aware of. Warnings are nothing to laugh at, and suppressing them by default seems like a recipe for grief.Oh, I agree, I just meant an option being available to suppress them. It would logically not be checked by default, obviously. It exists on the commandline so I wasn't sure why it doesn't exist in the GUI.

I'll be trying it on DTS for Pirates of the Caribbean in a bit.

[delacroixp]

Matroska does support changing of private codec data in the middle of the stream, but this feature is not widely supported (if at all, Haali's splitter might be the only app supporting this at the moment).

However, Matroska's header fields may NOT change mid stream. Therefore the answer is more likely "no".
With critical-mass... menus, stereoscopic3D and various advanced features will undoudtedly take-off.

Thanks for your time...


:):D:eek:
Pascal

[Neo Fagin]

I've changed something in the MPEG reader code lately, but I think I haven't built a new Windows build with those changes. Let me do this now. (goes away for a minute) Here you go. Please download this build and test against the files that produce those warnings:
http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.0.2-build20070530-1.rarI just tried this on another DTS file made with Surcode and it is still rather slow compared to the commandline with -q, though not "20K per second" slow like it was. It writes about 1MB/sec versus the commandline with -q writing about 4MB/sec.

[Mosu]

Hmm, so it still does not skip the appropriate amount of byets... I hate MPEG. Could you please upload 10 MB of your file? Thanks.

[Neo Fagin]

Hmm, so it still does not skip the appropriate amount of byets... I hate MPEG. Could you please upload 10 MB of your file? Thanks.

D'oh I deleted it, but I'll make another one and up it later today.

[delacroixp]

D'oh I deleted it, but I'll make another one and up it later today.
What happened to the recycle bin... or do you also shift-delete or possibly even use a shredder...


:):D:eek:
Pascal

[bob0r]

@Mosu

Any news on fixing Nal-Size on H.264 muxed .mkv files?
The ones with nal size 3 can't be played with the latest cyberlink H.264 decoder.

If no news yet, or not possible soon, can you advice me on how to "fix" the nal-size by remuxing, but keeping the same audio delay? (extra question: How can we see audio delay used in a muxed .mkv file?)

A method used now is:
Demux video from .mkv
Open wrong bad .mkv, select audio only
Then open the H.264 video again and remux with nal-size 4

P.S.
Why is nal-size 3 still selectable?
For H.264 its not valid, but for other video formats it is?

[delacroixp]

I made 3xH264 encodes of 'Band of Brothers 1'... over-sampled or upscaled to 1440x800, 1280x720 and 1024x576... @ Q23, Q22 and Q19 respectively...
I also made 3xMP4a audio tracks... 5.1 surround @ 48 KHz (full dynamic range), 5.1 surround @ 44.1 KHz (reduced dynamic range) and 2.0 stereo (reduced dynamic range)...
I then muxed the lot, hoping that a friend of mine could do a quality comparison of BoB 1 at each of the 3 encode resolutions on his 40 inch HD LCD TV.

The muxing goes fine but I can't switch video tracks in Zoom Player... the other track is ticked, but not played...
what gives... ???


:):D:eek:
Pascal

[KoD]

This is very likely not muxing related, but playback related. Your decoder maybe doesn't like switching from 48KHz to 44.1KHz without being resetted or something like that.