mkvtoolnix 1.0 is out :)

[Mosu]

Originally posted by jk888
Bummer... I was suspecting this will happen, half finished nero AVC files can't be fixed I noticed. Don't worry Mosu I have an alternative plan, I'll encode this 20s commercial I got. I'll upload it sometime this week.

Sounds good :) As long as the crash happens with that file, too. Please check that before uploading :)

Thanks for your work.

[jk888]

Well I'm uploading the full nero AVC file again now, because the 20s commercial I encoded worked! It was a 2mb AVC file and I muxed it into mkv fine without crashes or errors. But I couldn't play it because mkv defaults to the ffdshow decoder. We won't be getting AVC support from ffdshow anytime soon, so is there a way to set AVC Matroska files to use the Nero AVC decoder by default?

Also The AVC that failed wasn't related to any settings within mkvtoolnix, because I even tried just to add the AVC then mux it with the default settings (without splitting as well), and it still crashed.

[jk888]

Hi Mosu, uploaded completed, you have the entire AVC file now. I look forward for a fix.

[compunerd632]

I seem to have encountered a bug with setting the delay on the audio track. This is a 2 channel vorbis track. It's supposed to have a 16ms delay, but when I played it back there was a slight lipsync problem. I loaded the file in VirtualDubMod and it indicated the delay as 1ms. I tried again with 50ms to see what would happen and again it was only 1ms. I tried a value of -16 to see if it handles negative delays correctly and this time it ended up with 19ms. I'm using the latest release dated December 18 I believe.

[Mosu]

Originally posted by compunerd632
I seem to have encountered a bug with setting the delay on the audio track. This is a 2 channel vorbis track. It's supposed to have a 16ms delay, but when I played it back there was a slight lipsync problem. I loaded the file in VirtualDubMod and it indicated the delay as 1ms. I tried again with 50ms to see what would happen and again it was only 1ms. I tried a value of -16 to see if it handles negative delays correctly and this time it ended up with 19ms. I'm using the latest release dated December 18 I believe.

You can't use VDub to show the delay that mkvmerge produces (or doesn't produce). mkvmerge will add silence or remove packets at the front of the audio stream and only offset the timecodes if a full packet cannot be removed/added without adjusting too much. So you should check _visually_ after each muxing.

BTW: I doubt that you can really see a 16ms delay. Normally people start noticing delays at around +-30ms. Most are fine with +-40ms.

[stephanV]

the duration of a video frame at 29.97 fps is 33.4 ms, any delay below that should virtually be impossible to detect...

[Mosu]

Originally posted by jk888
Hi Mosu, uploaded completed, you have the entire AVC file now. I look forward for a fix.

Thanks. The problem was that I was interpreting the values in the CTTS atom ("frame timecode offsets") as unsigned 32 bit values while they seem to be signed 32 bit values. A one-line fix ;)

You can try http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/HEAD//mkvtoolnix-head-20050115-1.rar

[jk888]

Well the muxing part worked, I have everything in a mkv container now. But I have no idea if it's playable, because both MPC and Showtime can't play the file! MPC defaults to the ffdshow filter which doesn't support AVC. And Showtime plays the file but all I see for the video is grey screen.

I can't confirm if it worked or not...

[Mosu]

Originally posted by jk888
Well the muxing part worked, I have everything in a mkv container now. But I have no idea if it's playable, because both MPC and Showtime can't play the file!

You need a current build of Haali's splitter and Nero's decoder for it to work as far as I know. Decoding with ffdshow doesn't work yet as Haali told me.

[jk888]

I do have the latest Matroska filter from Haali already, just to be safe I downloaded it again from Haali's site and tried it again. No go, same problem. The issue is not the splitter because playback just keeps defaulting to the ffdshow filter, if I can get it to use the Nero decoder then things might work. How do I change it from defaulting to ffdshow all the time?

[opsis81]

@ Mosu

I have downloaded the latest mkvtoolnix from http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/HEAD/
Each time I try to mux a mp4 file with ASP video mkvtoolnix muxes it as
V_MS/VFW/FOURCC,DIVX :devil:
I would like to be muxed as V_MPEG4/ISO/ASP
I don't like VFW very much :D
I also tried to add --engage native_bframes to my cmdline but it din't work.
mp4 files with AVC video work OK.I get V_MPEG4/ISO/AVC
Haali's splitter has native MPEG4 support now so I wouldn't have any problem in playback.

[filewalker]

I just tried to mux a MP4 file (AVC video/ AAC audio)to MKV with latest build(20050115-1), but I get this message after muxing:Warning: Quicktime/MP4 reader: Unknown/unsupported FourCC 'avc1' for track 3
If I open the file with latest parser I just get only the AAC stream as output from the parser (tried in Graphedit)...
(and if I open this MKV file in MKVMerge it also shows me that there's only the AAC stream inside)

Cu

[Mosu]

Originally posted by opsis81
@ Mosu

I have downloaded the latest mkvtoolnix from http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/HEAD/
Each time I try to mux a mp4 file with ASP video mkvtoolnix muxes it as
V_MS/VFW/FOURCC,DIVX :devil:

I know, native MPEG4 level2 (aka DivX aka whatever aka V_MPEG4/ISO/ASP) is not finished yet. It will be included in the 1.2.0 release (just like AVC).

[Mosu]

Originally posted by filewalker
I just tried to mux a MP4 file (AVC video/ AAC audio)to MKV with latest build(20050115-1), but I get this message after muxing:

Uhm... That's a sure sign that you're not using 1.2.0 but something earlier. Could you check mmg's "settings" tab? Maybe if still points to an older mkvmerge.exe.

[opsis81]

Thank Mosu for answering.
I will be waiting for new builds:)

[Mosu]

Originally posted by jk888
The issue is not the splitter because playback just keeps defaulting to the ffdshow filter, if I can get it to use the Nero decoder then things might work. How do I change it from defaulting to ffdshow all the time?

I've asked Haali on IRC and he said the following:


[.23:58:51.] Haali:: Mosu: i found out you need to turn off all of mpeg1/mpeg4/avc in ffdhow settings
[.23:59:20.] Haali:: err no
[.23:59:26.] Haali:: mpeg1/mpeg/avc
[.23:59:29.] Haali:: mpeg4 is ok
[.23:59:41.] Haali:: haha it was mpeg2
[.23:59:50.] Haali:: my keyboard is not working properly today
[.23:59:52.] @Mosu:: ?
[.00:00:00.] alexnoe:: give it back to toff then
[.00:00:15.] @Mosu:: so he has to deactivate ffdshow's mpeg1/mpeg2/avc handler, then the nero decoder will be used instead?
[.00:00:16.] Haali:: Mosu: there is a codec settings page in ffdshow where you select what it decodes
[.00:00:24.] Haali:: yes, that's it
[.00:00:57.] planet1:: anyone using the 1by1 player ?`
[.00:01:00.] Haali:: for some reason ffdshow will connect to avc pin if it's set to decode mpeg2 but not avc

[Mosu]

Some more info from Haali about AVC:

[.00:08:31.] Haali:: Mosu: btw, avc now works in ffdshow-20050112.exe
[.00:08:37.] Haali:: even seeking is ok

[filewalker]

Ok, thanks...my fault.:( sorry!

I have two versions of MKVMerge(the normal and the new experimental build)...and for the latest I forgot to change the path to the new .exe.

...muxing works fine now! :) and playback,too. :) really cool :thanks:

Cu filewalker

[jk888]

Hi Mosu, it's confirmed that the version of mkvtoolnix you gave me works, it muxed and split AVC in MKV without problems. Eventually I was able to play the file after getting some instructions on force playback using the new Haali splitter.

[RanmaSaotome]

I just muxed a nero avc video into .mkv using mkvmerge but the resulting video plays too fast. Its a 12fps anime video. Is there a way to tell .mkv what the frame rate should be, as the file plays ok in the .mp4 container?

[RanmaSaotome]

Never mind, its an FFDshow issue as nero digitals video decoder decodes at the correct fps.

[frodoontop]

A small bug report:

When I encountered a subtitle with the code "iw" mapped to the language in the .idx file, the language wasn't recognized by mmg. (Should be Hebrew). This is for mkvtoolnix 1.0, so it may already be solved.

[Mosu]

Originally posted by frodoontop
A small bug report:

When I encountered a subtitle with the code "iw" mapped to the language in the .idx file, the language wasn't recognized by mmg. (Should be Hebrew). This is for mkvtoolnix 1.0, so it may already be solved.

Hmm, "iw" is not an official ISO639-1 code (those are used on DVDs). "he" is the official one for Hebrew. But I can add "iw" for that, too.

[thana]

hi!

i have two problems with the chaptereditor of mmg:

- chapters saved with mmg-1.01 can't be opened with mmg-pre1.2, it gives the following errormessage: "could not open [file] for reading". which is obviously wrong in itself too, because after removing the line "<EditionProcessed>0</EditionProcessed>" from the file it is loaded fine.

- it is possible to save chapter files that can't be loaded afterwards anymore in both the latest official and latest beta version of mmg, by setting an empty (first entry in the dropdown) language and/or country value for a chapter entry. "verify" doesn't seem to find problems before saving. the resulting xml contains an empty tag, f.e. "<ChapterLanguage></ChapterLanguage>", and mmg refuses to load it again.


and a suggestion for a small usability enhancement:

after typing in the name for a chapter entry and hitting enter mmg should jump to the next chapter entry, set the cursor to the name field and select the complete text. in this way you could type in all chapter names quickly without having to constantly switch between mouse and keyboard.

[cheburashka]

Looks like a bug in the latest beta mkvtoolnix-20050120-1:

When put AVC stream from MP4 file using latest build , aspect ratio isn't set in resulting MKV file unless you manualy set it up.

__________________________
I love Матрёшка (Matroska):p

[Mosu]

Originally posted by cheburashka
Looks like a bug in the latest beta mkvtoolnix-20050120-1:

When put AVC stream from MP4 file using latest build , aspect ratio isn't set in resulting MKV file unless you manualy set it up.

It should be (I have implemented that), but maybe it's not working for all files. I need that file. Could you upload it to my FTP server, please?

[Mosu]

Hey,

I've fixed these issues in http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/HEAD//mkvtoolnix-head-20050122-1.rar

Originally posted by thana
- chapters saved with mmg-1.01 can't be opened with mmg-pre1.2, it gives the following errormessage: "could not open [file] for reading". which is obviously wrong in itself too, because after removing the line "<EditionProcessed>0</EditionProcessed>" from the file it is loaded fine.

There were two issues. The first is the wrong error message. It is now the correct one: "<ABC> is not a valid child element of <DEF>." The second is that old files should be readable by newer mmg/mkvmerge versions. I've addressed this by simply ignoring old legacy elements like EditionProcessed.

- it is possible to save chapter files that can't be loaded afterwards anymore in both the latest official and latest beta version of mmg, by setting an empty (first entry in the dropdown) language and/or country value for a chapter entry. "verify" doesn't seem to find problems before saving. the resulting xml contains an empty tag, f.e. "<ChapterLanguage></ChapterLanguage>", and mmg refuses to load it again.

Haven't fixed that yet (also due to the forum being down; I didn't remember all the issues you've written about). Will come later.

after typing in the name for a chapter entry and hitting enter mmg should jump to the next chapter entry, set the cursor to the name field and select the complete text. in this way you could type in all chapter names quickly without having to constantly switch between mouse and keyboard.

Implemented as well. Enter will cycle through all chapters on the first level below the editions.

[jk888]

Originally posted by Mosu
It should be (I have implemented that), but maybe it's not working for all files. I need that file. Could you upload it to my FTP server, please?

It stopped working after the Jan.15 build. Please don't ask me to upload it, last time it took like 3 days to upload.

Sadly, Windows platform users have to put up with a long list of bugs with mkvtoolnix just because Mosu doesn't want to invest in a Windows system. We're just not getting the same support as Linux users.

Mosu will actively fix bugs for the Linux platform whenever he encounters them. But for the Windows platform he has to rely on the Windows end-users to encounter them and report them. That's very fustrating for Windows users. The worst is sometimes those bugs are so simple (like the AR bug), that if Mosu had a windows system a simple test prior to new releases would have encountered them.

I knew about the AR bug a week ago already, I just didn't want to bother reporting it, cause I don't have time to upload my file for another 3 days. The Jan 15 build works great for me, I can live with that for a long time.

[Mosu]

Originally posted by jk888
It stopped working after the Jan.15 build. Please don't ask me to upload it, last time it took like 3 days to upload.

Ok, I'll look into it.

Sadly, Windows platform users have to put up with a long list of bugs with mkvtoolnix just because Mosu doesn't want to invest in a Windows system. We're just not getting the same support as Linux users.

This is SO not true! I get WAY more bug reports from Windows users, and I try to fix them all. Same for Linux, I just don't get as many, probably because there are so many more users with the Windows version of mkvtoolnix.

The worst is sometimes those bugs are so simple (like the AR bug), that if Mosu had a windows system a simple test prior to new releases would have encountered them.

I'm sorry that you feel this way, but that AR bug has nothing to do with Windows or no Windows. I could also have tried muxing such a file and watching it on Linux. But I didn't. Why? Because I assumed that it was still working. Another reason? Because I don't own Nero Recode and cannot create such files myself.

I knew about the AR bug a week ago already, I just didn't want to bother reporting it, cause I don't have time to upload my file for another 3 days.

I don't need an upload in all cases. Most of the time (if not all the time) I try to reproduce the bug myself with stuff that I already have. There's no use in me waiting for a user to upload a file if I can fix it right now.

So please, PLEASE don't be afraid to report bugs. I'm grateful for each report that I get. And it's also perfectly fine to say that you don't have the time to/don't want to upload such a big file. I will understand and respect that and try to find another solution.

The Jan 15 build works great for me, I can live with that for a long time.

See, that's a very useful hint for me. Just some more info I might need: If you mux with a newer build and run mkvinfo on it (mkvinfo does have a GUI, btw, you can create a shortcut to it and add "-g" to is command line), what are the pixel and display dimensions for that broken case? And the same info for the case that's working, please. Thanks.

[iapir]

Originally posted by jk888
Sadly, Windows platform users have to put up with a long list of bugs with mkvtoolnix just because Mosu doesn't want to invest in a Windows system. We're just not getting the same support as Linux users.

Mosu is probably the least person not to care about users' problems. IMO this critic is unfair, as so far there were never any bug that he couldn't fix... For Windows, Linux and OS X (and probably others).

[jk888]

Originally posted by iapir
Mosu is probably the least person not to care about users' problems. IMO this critic is unfair, as so far there were never any bug that he couldn't fix... For Windows, Linux and OS X (and probably others).

I started here 1 1/2 year ago during the 0.6 builds. I reported the missing subtitles bug for muxed vobsubs. Mosu fixed the problem, then I didn't use any new builds for a whole month. Later on I found out all the new builds had the same missing sub problem again. I was lazy and didn't report it, I thought someone will find out eventually. Then another month later mkvtoolnix was on the 0.7-0.8 builds and the bug was still there...

So in the end I reported it, if I didn't we probably still don't have vobsubs in mkv.

There's a difference between a developer who proactively looks for bugs and one who waits for users to report them.

Probably the simplist solution is to test encode each build before releasing it, and test it on a Windows platform.

[Mosu]

Originally posted by jk888
Probably the simplist solution is to test encode each build before releasing it, and test it on a Windows platform.

I do have automated tests for such a purpose. They compare hash values of newly muxed files with known hashes. That way I usually see when something changes. One problem, though, is the number of different options and formats that mkvmerge supports. It's very hard to write tests that cover all possibilities.

However, I accept your criticism and give writing more tests a higher priority.

About AVC. AVC is very new. Approximately 10 days ago Haali and I finally figured out how to do it correctly. That's why there are no tests. It's so new that tests are not useful at all because the way AVC is stored changed too often. All mkvtoolnix builds since then were also clearly in the "pre" directory. My signature says that 1.0.1 is the latest release. So anyone trying out such a "pre" build should be aware that this is a development version. Not a final release.

About the AR problem: I don't need you to remux with the old version anymore. I have files here which have the same problem, so I can track it down myself.

[jk888]

I'm glad you are taking this criticism constructively. I just wanted to complain to get the fustration out of my head. I look forward to future builds of mkvtoolnix.

[filewalker]

I can't understand the world anymore!:confused:

Mosu makes a great job here. He responds to every question and fixes bugs as fast as possible.
...and now he gets bad crisism and just demands...he spend his free time for his Matroska doing....his FREE time!

a little reminder for everyone who hasn't read DDogg's story:
http://forum.doom9.org/showthread.php?threadid=51632&highlight=story


Mosu, I appreciate your great work! Thanks.

Cu

Btw. for uploading of small files...just splitt the file in MKVMerge during muxing to 2 or 3 Mb

[Mosu]

Originally posted by filewalker
Btw. for uploading of small files...just splitt the file in MKVMerge during muxing to 2 or 3 Mb

Well, the last file I asked him to upload was a 1,4 GB MP4 file that mkvmerge crashed on :/ So there really was no way he could make it smaller. As it turned out the problem only occured when timecodes became pretty big. Therefore my small MP4 files didn't crash mkvmerge. And I can understand that it sucks uploading that much at 14 KB/s ;)

[filewalker]

Yep, I read that it was a big upload...but on a closer look I mixed cheburashka's upload and thought it was jk888's second one...sorry...but, well, it was just intended as a hint for everone, generally.

Cu

[Mosu]

This build should fix the broken aspect ratio handling for AVC: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/HEAD//mkvtoolnix-head-20050125-1.rar

[cheburashka]

@ Mosu
I just checked the latest build.
The AR bug fixed, thank you.

@ filewalker
The big size upload isn't mine. I was going to upload 35K size m4 file produced from Version.avs by Nero Recode, but was buzy last days and didn't upload it.

[thana]

i have found one more bug in the mmg chapter editor (version mkvtoolnix-head-20050125-1):
when you save a chapter-file over an already existing file, the existing file doesn't get cleared but only overwritten, and the filesize only ever gets bigger but never smaller. so if the size of the chapter-file was smaller than the existing file, garbage from the existing file is still present after saving (beginning after </Chapters>). i hope you know what i mean, it's difficult to describe :)


and just a reminder for this bug, so it doesn't get lost:
Originally posted by thana
- it is possible to save chapter files that can't be loaded afterwards anymore in both the latest official and latest beta version of mmg, by setting an empty (first entry in the dropdown) language and/or country value for a chapter entry. "verify" doesn't seem to find problems before saving. the resulting xml contains an empty tag, f.e. "<ChapterLanguage></ChapterLanguage>", and mmg refuses to load it again.
Originally posted by Mosu
Haven't fixed that yet (also due to the forum being down; I didn't remember all the issues you've written about). Will come later.

all the other things you fixed/added are working great, thx!

[Mosu]

Originally posted by thana
i have found one more bug in the mmg chapter editor (version mkvtoolnix-head-20050125-1):
when you save a chapter-file over an already existing file, the existing file doesn't get cleared but only overwritten, and the filesize only ever gets bigger but never smaller.

Yikes! That's another one-line fix ;)

and just a reminder for this bug, so it doesn't get lost:

all the other things you fixed/added are working great, thx!

Don't worry, I haven't forgotten about it. I'm just pretty busy at the moment and hardly work on mkvtoolnix. And now it seems I'm coming down with a cold as well. Short: It will be fixed.

[Shinobu]

i'm used to use one build of mmg of the 01/01/2005 to mux my avc + aac (both nero) + srt and it works perfectly (with haali spliter and ffdshow).

but when i use any newer version of mmg, and mux avc + aac the resulting mkv is realy choppy and when i watch the decoding informations in ffdshow, the fps is set up to 25 (for pal encoding so it's ok) but the decoding fps jump between 10 and 60 constantly.

if anyone as an idea ^^.

(if a ftp is is open i can upload 2 samples, one ok and one choppy)

++

[Mosu]

Originally posted by Shinobu
(if a ftp is is open i can upload 2 samples, one ok and one choppy)

Yes, that'd be nice. See my signature for the info.

[JasonFly]

I have the same problem that shinobu have.

Decoding an avc with a version of ffdshow works perfectly when in an .mp4

But the playback is really choppy when played inside an mkv. But in this case(mkv) decoding works perfectly with nero decoder. Would you like an other sample or the one of shinobu will be enought?

But I didn't know that the 01/01/2005 version didn't do that.

PS:
This mkv is avc+heaac+vobsub

[Shinobu]

8mo sample is it ok for you ?
if it's ok i'll start upload ^^

the 01/01/2005 version for test : http://satsuki.yatoshi.free.fr/mkv.exe (7z auto extact file)

++

[Mosu]

Originally posted by Shinobu
8mo sample is it ok for you ?
if it's ok i'll start upload ^^

Sure. Go ahead :)

[Shinobu]

strange when i make sample of about 8mo i don't have the bug.... might have something to do with the file size ....
i'm doing again a full mux of the whole file (4.5go) and if the bg is still here .....

++

[Mosu]

Originally posted by Shinobu
strange when i make sample of about 8mo i don't have the bug.... might have something to do with the file size ....
i'm doing again a full mux of the whole file (4.5go) and if the bg is still here .....

++

If the bug is still there with the big file then you don't have to upload the full file. You could start uploading and simply abort the upload after e.g. 15 MB. If we can't figure out the problem from that short file then we'll think of something else :)

[Shinobu]

error of diagnostic here can't reproduice the bug on my computer too many tests of filter have propably corrupted my computer...

the 2 samples are posted i hope you can make it bug...

++

[kurt]

Originally posted by JasonFly
I have the same problem that shinobu have.

Decoding an avc with a version of ffdshow works perfectly when in an .mp4

But the playback is really choppy when played inside an mkv. But in this case(mkv) decoding works perfectly with nero decoder. Would you like an other sample or the one of shinobu will be enought?

But I didn't know that the 01/01/2005 version didn't do that.

PS:
This mkv is avc+heaac+vobsub

same problem here: mkv (avc+AC3) works fine with nero decoder, but not by using latest ffdshow build(s)... (choppy playback)...
Edit: I installed latest Haali-splitter...

[Shinobu]

@kurt & Jasonfly

could you try the build i post (01/01/2005) and tell me if it's produice no-choppy mkv for you too.

can help the devs ^^

++