PDA

View Full Version : mkvtoolnix 1.0 is out :)


Pages : [1] 2

Mosu
17th November 2004, 15:32
Hey,

Finally! Here it is: mkvtoolnix 1.0

I've meant to release this for over a week now, but something always got in the way. But no longer :) After...

- nearly one year and ten months after joining the Matroska team on 2003-01-14,
- over one year and five months since the first public release on 2003-06-12,
- writing more than 62000 lines of code, documentation and examples,
- a LOT of bugs,
- as many bug fixes,
- way too many hours of coding, idling on IRC, writing mails and posts to various forums

... I've decided to call this release 1.0.

And I'm REALLY happy to have gotten this far. Because to be honest -- I don't do this for myself. If I was I would have stopped a long time ago, because the features that I want and need have been there for quite some time now. No, I work on this project for three reasons:

1. Fame,
2. Money,
3. becoming the Supreme Overlord of the Known Universe.

Less important reasons are:

1. I believe that Matroska is a great project, and that the multimedia scene needed such a container.
2. You ask for it :) Seriously. Your constant feedback (be it bug reports or feature requests) tells me what I've done wrong and what you need. I really prefer doing things that a lot of people can use over doing things only I might need. So everyone out there contributing to the project, coding for Matroska, sending patches, reporting bugs, nagging me about new features, providing sample files (!), sending a nice postcard or a nice cup from this year's European championship in Portugal (!!) -- a big THANKS from my side to you all. You keep the project going as much as I do.
3. I like coding in general, and I like coding on this container level in particular. It's fun :)

So what have I accomplished? Well, mkvtoolnix can handle a small number of different containers and flat file formats like

- AAC,
- AC3,
- AVI
- DTS,
- FLAC,
- Matroska ;)
- MP3,
- Ogg/OGM,
- Quicktime/MP4,
- RealMedia,
- SRT,
- SSA/ASS,
- TTA,
- VobSubs and
- WAV.

It can deal with a number of different codecs, meaning it knows exactly how to put them into Matroska:

- AAC,
- AC3,
- DTS,
- FLAC,
- MP3,
- PCM,
- RealAudio,
- RealVideo (pretty much all versions),
- SRT,
- SSA/ASS
- TTA,
- different video formats,
- VobSubs,
- Vorbis

On top of that mkvmerge can handle attachments, chapters, tags, reorder tracks... There is a totally horrible GUI called mmg ;) which is probably the reason for mkvtoolnix' success on Windows (even though I really, really don't like GUI programming). There's a tool that can get most of those tracks out of a Matroska file into other container formats again. And there's a tool for getting information on a per-element level from a Matroska file.

Quite some work, I assure you, but you know why I keep on doing this :)

Another round of thanks goes out to the "core" of the Matroska team and those who don't consider themselves a member of the team but who've done tremendous work nevertheless (/me waves to alexnoe ;)).

Where will I go from here? A few months ago I posted a "1.0 release plan", and I haven't changed my expectations since then. I will continue the 1.0 line with bug fixes only. I've started working on another code branch, often called 'trunk', which will result in a releast "1.2" next year. This is where new features will be implemented like support for MPEG1/2 video (already working on that,
good progress), support for native MPEG4, support for appending / concatenating files (already working on that with very good progress), partial redesign of mmg etc. The "1.0" release line will stay stable and (hopefully) mostly bug free.

And now to the usual links to...
... the home page:
http://www.bunkus.org/videotools/mkvtoolnix/
... the source code:
http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-1.0.tar.bz2
... the Windows binaries:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-1.0.rar

Binary packages for Debian, FedoraCore and SuSE have already been built and uploaded to the home page.

Here are the final changes between 0.9.7 and 1.0:
---------------------- cut -----------------------------
2004-11-10 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The Matroska reader doesn't insist on having a default duration ( = FPS) for video tracks in the "AVI compatibility mode" ( = with the CodecID "V_MS/VFW/FOURCC"). This enables re-muxing of Matroska files created from MP4 files.

2004-11-05 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: File names with non-ASCII characters were not working if mmg was compiled against a Unicode enabled wxWidgets.

2004-11-04 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Added reading DTS from AVIs and from Matroska files.
* mkvmerge: bug fix: A variable initialization was missing which very recent gcc versions (3.4.2) did not like very much. Also fixed a small compilation bug.
---------------------- cut -----------------------------

You see, a couple of small bug fixes and small additions. Nothing major, and nothing to worry about.

That's it for tonight. Have fun :)

Mosu

buzzqw
17th November 2004, 16:52
thanks for your effort and time !!

my worst fear(? my english isn't so good) was Matroska would become a dead project, but i am very happy of Matroska (muxer...) and player (more or less) support.

I will suggest to use over and over.

Thanks again

a very happy muxer

BHH

thana
17th November 2004, 18:00
congratulations and a big 'thank you' from me too!

i believe mkvtoolnix is a big part of the reason, why matroska is where it is today. it made all those little (or sometimes big) things, where matroska is superior to other containers, so easy to use, that you are hard pressed NOT to use all of them. and i just like it to use a container that is "hack-free", even if it sometimes only makes a difference in my mind. ;)

also i appreciate the separation in commandline-tools and a gui very much, i use them both on a regular basis. there's nothing more conveniant than setting up a batch file for 100+ files and letting mkvmerge do its job for the next hours. OTOH mmg is really fantastic for your everyday mkv-mux-job. and i don't agree that its bad designed (i've seen much worse ones). :D

i'm already excited about the features that version 1.2+ will bring us. if you need someone to test them don't hesitate to ask, i bet there are more than enough users here which would be glad to help you. and i will of course continue reporting bugs, but there really wasn't much to report the last months (a good sign for 1.0). :)

Tuesday
17th November 2004, 18:39
Big thanks to Mosu for all his hard work, if it wasn't for MMG i wouldn't be using matroska today - and that would be a shame as it is such a useful tool.

I can't code myself but i'm pretty sure its not easy :p so cheers for doing all the hard work for us!

Teegedeck
17th November 2004, 18:44
Yay! Let me express my heartfelt congratulations and thanks! :)

People like you breath life into ideas! I've always followed the development of mkvtoolnix with great interest and sympathy. The way you work closely together with the mkvtoolnix users is especially noteworthy. You've delivered working solutions to problems and feature requests on very short notice.

I hope to see you continue your work on mkvtoolnix - and maybe start other stuff - in that same wonderful spirit.

Thanks, Mosu!

outlyer
17th November 2004, 18:50
Once again, thank you for the many many hours you've spent in this thing :)

Let's hope you get fame and money. I'm not that sure about universe domination... :D

CONGRATULATIONS

KpeX
17th November 2004, 19:55
Congrats Mosu, and looking forward to future developments. :)

Your work should be an inspiration to other open-source / free software developers, especially your attention to user feedback and understanding of the value of the windows user-base.

filewalker
17th November 2004, 20:09
1.0 that's really very nice news!:) :) :)

Thanks mosu for your hard work.


Cu filewalker

ssjkakaroto
17th November 2004, 20:12
Congratulations Mosu ;)
mkvtoolnix is a essential tool for me thx to all the effort you've put in it, i'm really looking forward to see how far it can go!
thx a lot m8

JasonFly
17th November 2004, 20:46
Thank you for all your work Mosu. I have followed the development of mkvtoolnix since approximately one year and it's amazing the things you've manage to create. There was Vobsub handling, aspect ratio, chapters and many many other features that I don't use but that some other people might.

mkvtoolnix has gone far beyond my expectations in terms of features and that deserve a big thank you.

spolja
17th November 2004, 23:08
:thanks:

sterlina
17th November 2004, 23:23
- nearly one year and ten months after joining the Matroska team on 2003-01-14,
- over one year and five months since the first public release on 2003-06-12,
- writing more than 62000 lines of code, documentation and examples,
- a LOT of bugs,
- as many bug fixes,
- way too many hours of coding, idling on IRC, writing mails and posts to various forums:D

great coder!! thanks!!

GrEEk_OuTcAsT
18th November 2004, 00:11
Thanks for your great program mosu. You did something more than awesome job.

E-Male
18th November 2004, 00:12
a well deserved 1.0

thx for all the work you put into this

darkavatar1470
18th November 2004, 01:34
I've been trying to get ppl use mkv for a long time,
and a 1.0 "stable" muxer would make it easier...

Big Thanks again for your hard work !

Hiro2k
18th November 2004, 05:18
Congratulations Mosu!!!

I've always apreciated all your hard work on these forums and I'm glad to have seen this code mature so quickly. You efforts are most apreciated by the entire comunity and we will always cheer you on.

This has already been said, but it needs to be emphesized!

Your work should be an inspiration to other open-source / free software developers, especially your attention to user feedback and understanding of the value of the windows user-base.




Thanks

aaar9800
18th November 2004, 06:14
I love you...

CruNcher
18th November 2004, 10:59
Congratulations to Mosu and the whole Matroska Team :)

IgorC
18th November 2004, 13:57
And what about supporting of container for H.264 (AVC1).

Mosu
18th November 2004, 17:02
Thanks for your kind words :) I really appreciate them.

from buzzqw:
my worst fear(? my english isn't so good) was Matroska would become a dead project, but i am very happy of Matroska (muxer...) and player (more or less) support.

You're quite right. We're a pretty small team, and if we hadn't been that committed Matroska could have died quickly. But I think we've established Matroska in the community now, so I don't really fear it dying any time soon.

I will suggest to use over and over.

Great :) Spread the word :D

from thana:
also i appreciate the separation in commandline-tools and a gui very much, i use them both on a regular basis. there's nothing more conveniant than setting up a batch file for 100+ files and letting mkvmerge do its job for the next hours.

Oh my God. 100+ files? You're insane :D But other than that I couldn't agree more :)

The separation is probably more the result of an evolutionary coding process. Before mkvtoolnix I hadn't done any serious GUI work, so doing a command line version first (or doing only a command line version) was the way to do. Around version 0.6 Florian Wagner joined us and wrote the first version of mmg. Unfortunately he was short on free time, so I decided to dive into it and do the whole thing myself.

Looking back that was a very important decision because it opened mkvtoolnix for a much larger user base.

OTOH mmg is really fantastic for your everyday mkv-mux-job. and i don't agree that its bad designed (i've seen much worse ones).

I'm not saying that mmg is total crap (who would say something like that about his own baby?), but it's pretty overloaded with functionality. It doesn't have an online help, its dialogs are sometimes not self-explanatory (e.g. the fact that stuff in the chapter editor is NOT copied into the output file)... Maybe it's an average-to-good GUI, but I simply don't know enough about usability and writing GUIs to make it a 'very good' one.

i'm already excited about the features that version 1.2+ will bring us. if you need someone to test them don't hesitate to ask, i bet there are more than enough users here which would be glad to help you.

Sure, I will. I have to get three things done before I can create a first tets version that does file/track concatenation:

1. proper handling of chapters/tags,
2. handling of some evil cases like concatenating two VobSub files while concatenating two AVIs (e.g. you've downloaded something including external sub files and don't want to mux to Matroska first and THEN append but skip the first muxing step),
3. add that stuff to mmg :)

This time I'll definitely post a couple of test versions here before releasing 1.2.

and i will of course continue reporting bugs, but there really wasn't much to report the last months (a good sign for 1.0).

That was kinda my goal for 1.0 :)

from Tuesday:
I can't code myself but i'm pretty sure its not easy

Well, coding in general is probably as hard as doing well in other things like sports, arts etc. It's mostly how much you 'practice' and try to improve yourself. A certain level of understanding for abstraction, technical issues and mathematics does help, of course.

As for mkvtoolnix: Most of the stuff I deal with is not really hard in the sense that it requires genius to pull it off. Most is basic craftmanship/good engineering or whatever you want to call it. Hard work interfacing to libraries, findign out about file structures, thinking of good ways to implement this feature etc. But there are tough spots as well. For me the 'hardest' part is probably writing documentation (both for the code so that I or someone else knows what I wanted to do and for the usage of the programs themselves).

from Teegedeck:
I hope to see you continue your work on mkvtoolnix - and maybe start other stuff - in that same wonderful spirit.

I won't leave mkvtoolnix anytime soon :) At the moment I don't see other projects that I find as interesting as Matroska. Maybe when we all find the motivation to really start to work on our gstreamer&Matroska based video editor I'll pour as much time into that as I did with mkvtoolnix.

from outlyer:
Let's hope you get fame and money. I'm not that sure about universe domination...

What! No domination!?? :(

from KpeX:
Your work should be an inspiration to other open-source / free software developers, especially your attention to user feedback and understanding of the value of the windows user-base.

I have to admit that I often curse about Windows and my decision to support it. But that's only because there are a lot of subtle differences in how software works on Windows compared to Linux (compiled from the same source). On the other hand I learned a LOT making mkvtoolnix cross-platform compatible, and all in all I consider this to be a win for myself.

from darkavatar1470:
I've been trying to get ppl use mkv for a long time, and a 1.0 "stable" muxer would make it easier...

My thoughts exactly. That's why I'll continue the 1.0 branch with bug fixes. I don't expect to have many releases, but we'll see ;) New features will only be included in the upcoming 1.2 branch so that 1.0.x will be as stable and as bug free as I can manage.

from aaar9800:
I love you...

/me blushes :D

from IgorC:
And what about supporting of container for H.264 (AVC1).

That's definitely on my TODO list. I guess that transcoding it from AVI would be very easy but not the 100% "correct" way to do it. We definitely have to figure out how to do it correctly when reading it from MP4 files. Closely related is the subject of "native MPEG4 in Matroska" -- the never ending issue of how to timestamp B frames and adding support for that in the playback applications.

I won't forget it, but it's not right on top of my TODO list either.

Ok, enough text from me today. Again a heartfelt "thanks!" for your kind words.

vlada
18th November 2004, 22:28
Hello,
many thanks for the great program. I'm a happy user of it for a long time and I try to spread matroska whenever I get chance. I delieve it is a solution for the future.
I have an idea - what about making a poll for new futures in version 1.2? If I could, I would sort the futures priorities this way:

1) Support for h.264, because it is the most promissing codec. It will be probably used a lot in the near future. If you won't be fast enough, the MP4 container will be the winner.
2) MPEG-1/2, because it is used in DVB-S and DVB-T broadcasting and will be used probably for a long time.
3) Support for speex - a low bitrate codec for speech is sometimes very useful

For matroska itself I would see the following targets:

1) Menu system
2} Continue work on Haali's splitter.
3) Try to get support for matroska on some HW players.
4) Make a SW player supporting all futures that matroska offers. Maybe based on MPC, MPlayer or VLC.

I'm sure other people will have different priorities, so why not to make a poll?

Many thanks and best regards,

Vlada

McoreD
19th November 2004, 06:43
Congratulations Mosu! :)

Long live Matroska.

Splashdriver
19th November 2004, 11:25
A very Big thanx for all the work you put up to it. one question though. I can't open attachments anymore with the default apps. I get a "failed to open attachment file". Is this an already known problem?

Big THANKS;)

Mosu
19th November 2004, 12:25
Originally posted by Splashdriver
I can't open attachments anymore with the default apps. I get a "failed to open attachment file". Is this an already known problem?

I don't quite understand what you mean. Which application cannot open attachments? Do you mean that when you add an attachment with mmg that it breaks when you hit the "start muxing" button?

Mosu
19th November 2004, 12:40
Originally posted by vlada
Hello,
I have an idea - what about making a poll for new futures in version 1.2?

We've had such polls in the past for the general direction in which we should extend Matroska. The menu system was always pretty much the most requested feature ;) Unfortunately it is the most difficult to implement, too. But robux4 has made some great progress in extracting all the info from the DVD IFO files, and Haali is implementing support for that in his splitter. We'll see how it turns out :)

1) Support for h.264, because it is the most promissing codec. It will be probably used a lot in the near future. If you won't be fast enough, the MP4 container will be the winner.

MP4 will be the winner in any case, I'm afraid, simply because it's the "chosen one" in the media industry. Hardware DVD players will implement support for h.264 in MP4 (and MP4 in general) in the near future.

I've added it to my TODO list (https://www.bunkus.org/anthill/query.php?bug=104).

2) MPEG-1/2, because it is used in DVB-S and DVB-T broadcasting and will be used probably for a long time.

Spyder and I are already working on this (at least on muxing MPEG-1/2 ES into Matroska. Parsing MPEG PS will be more difficult.).

I've added it to my TODO list (https://www.bunkus.org/anthill/query.php?bug=105), too.

3) Support for speex - a low bitrate codec for speech is sometimes very useful

I'm not really sure that it is THAT important. You can get pretty nice results with Vorbis at very low bitrates, too. Nevertheless, I've added it to my TODO list (https://www.bunkus.org/anthill/query.php?bug=106).

For matroska itself I would see the following targets:

1) Menu system

Definitely one of the most requested things. I've said something about that above already.

2) Continue work on Haali's splitter.

He is, and we want to include it in our next codec pack in order to get more testing, and -- more importantly -- because we think that it is at least as good as if not better than Gabest's splitter.

3) Try to get support for matroska on some HW players.

I don't think (and most of our Matroska team members agree) that this will not happen. Hardware players have very limited resources regarding memory and CPU power. Matroska on the other hand supports too many different codecs. A hardware vendor would have to support such a wide range of codecs, too, in order to be able to say "we support Matroska". Matroska's EBML basis is not the problem here -- the problem is that for some codecs like RealVideo there simply are no efficient and small decoders available.

4) Make a SW player supporting all futures that matroska offers. Maybe based on MPC, MPlayer or VLC.

Definitely not mplayer ;) Its architecture sucks, you'll never be able to get things like a menu system working with it. And we already have TCMP. It's not a "Matroska project", but the two are connected.

LeMoi
19th November 2004, 17:09
sorry but i stil have my 'Warning: matroska_reader: exception caught' error that prevents me from remuxing some of the file i have previously muxed :(
and i have a file with aac sound (codec_id : A_MS/ACM), a video and a sound and a ssa, and when i want to remux to change the ssa, i have lots of warnings :
Warning: 'D:\file.mkv' track 2: The current packet's timecode is smaller than that of the previous packet. This usually means that the source file is a Matroska file that has not been created 100% correctly. The timecodes of all packets will be adjusted by 22ms in order not to lose any data. This may throw A/V sync off, but that can be corrected with mkvmerge's "--sync" option. If you already use "--sync" and you still get this warning then do NOT worry -- this is normal. If this error happens more than once and you get this message more than once for a particular track then either is the source file badly mastered, or mkvmerge contains a bug. In this case you should contact the author Moritz Bunkus <moritz@bunkus.org>.
Warning: 'D:\file.mkv' track 2: The current packet's timecode is smaller than that of the previous packet. This usually means that the source file is a Matroska file that has not been created 100% correctly. The timecodes of all packets will be adjusted by 22ms in order not to lose any data. This may throw A/V sync off, but that can be corrected with mkvmerge's "--sync" option. If you already use "--sync" and you still get this warning then do NOT worry -- this is normal. If this error happens more than once and you get this message more than once for a particular track then either is the source file badly mastered, or mkvmerge contains a bug. In this case you should contact the author Moritz Bunkus <moritz@bunkus.org>.
hundreds like that, and finally the sound is totally desynchronized :(
and i event can not extract the track with mkvextract, it says the codec-id is unrecognized :(

Mosu
19th November 2004, 17:21
Originally posted by LeMoi
sorry but i stil have my 'Warning: matroska_reader: exception caught' error that prevents me from remuxing some of the file i have previously muxed :(
and i have a file with aac sound (codec_id : A_MS/ACM)

Sorry, but there's not really much I could do about it. AAC in Matroska is stored without the ADTS headers, and A_MS/ACM does not packetize the sound correctly (much like it is in AVI...).

Ok, maybe there is a way to fix this, but I need the file first. Please upload it to my FTP server.

LeMoi
19th November 2004, 18:21
hum, i my file is 1 GB :/
i will try and up a splitted trunk of 10 MB

Splashdriver
19th November 2004, 19:21
I don't quite understand what you mean. Which application cannot open attachments? Do you mean that when you add an attachment with mmg that it breaks when you hit the "start muxing" button?

What I meant was that when I add attachments to a file with mmg, the attachments are actually muxed, but when I try to right click the file and view the attachments by clicking on the option "open with default apps" (under attachments), I got this error returned ( I hope I explained it better this time). Does this happen to anyone or am I the only one experiencing this problem right now?

Thanks in advance,

Splashdriver

Mosu
22nd November 2004, 21:22
From the previous thread:

Originally posted by Thana
a small bug i found in mmg up to the latest prerelease version (2004-11-11):

when i minimize the main window while muxing is in progress, it is impossible to restore it after muxing finished (except from taskmanager).

This pre-build should fix this issue: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-1.0-build20041122-1.rar

jkwarras
22nd November 2004, 22:47
As other said, if it wasn't because of mkvtoolnik (and mmg gui) I'll probably have never used matroska.

So, I just wanted to say :thanks:

thana
23rd November 2004, 02:42
Originally posted by Mosu
This pre-build should fix this issue: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-1.0-build20041122-1.rar hmm, it doesn't really fix it, now it's just not possible to minimize the main window anymore. the minimize/maximize buttons of the main window don't react when the process window or the job manager is open. and clicking on the minimize button of one of those just puts the main window in the background, and it's impossible to reach f.e. a desktop-icon behind it.

Mosu
23rd November 2004, 09:26
Originally posted by thana
hmm, it doesn't really fix it, now it's just not possible to minimize the main window anymore.

Correct. If you want to minimize the whole thing then you'll have to minimize the front dialog instead. This minimizes all windows if the front window is modal (which it is in mmg).

(Side note: On Linux it seems to depend on the Window manager used. Most WMs allow the user to minimize all windows separately no matter if the other windows are modal or not, and they also don't seem to have that "stuck being minimized" problem either.)

thana
23rd November 2004, 17:23
Originally posted by Mosu
Correct. If you want to minimize the whole thing then you'll have to minimize the front dialog instead. This minimizes all windows if the front window is modal (which it is in mmg). no, it doesn't here. as i said above:
... clicking on the minimize button of one of those just puts the main window in the background ...
where "one of those" means the front window (processing or job manager). and "in the background" means behind all other windows, but not minimized.
sorry if that was unclear.

Mosu
23rd November 2004, 20:35
Originally posted by thana
where "one of those" means the front window (processing or job manager). and "in the background" means behind all other windows, but not minimized.

Ah ok, yes I see the problem, but I don't have a clue how to fix that (my limited knowledge in all things GUI is coming back to haunt me). I'll ask for help on the wxWidgets mailing list.

thana
23rd November 2004, 21:03
just to clear up the confusion:

the way the windows worked in the original 1.0 release was already perfect! you could completely minimize the main window, and restore it by clicking in the taskbar, like expected. the only problem was, that you couldn't restore it when the muxing finished while it was minimized.

Mosu
23rd November 2004, 21:08
Originally posted by thana
just to clear up the confusion:

the way the windows worked in the original 1.0 release was already perfect! you could completely minimize the main window, and restore it by clicking in the taskbar, like expected. the only problem was, that you couldn't restore it when the muxing finished while it was minimized.

No, it wasn't perfect. You've mentioned one of the reasons. The other is that in that version the controls in the main window were still usable even when the muxing dialog was shown, and that is definitely not wanted (because mmg cannot cope with it).

RedDwarf69
25th November 2004, 18:27
Originally posted by vlada
I have an idea - what about making a poll for new futures in version 1.2? If I could, I would sort the futures priorities this way:

1) Support for h.264, because it is the most promissing codec. It will be probably used a lot in the near future. If you won't be fast enough, the MP4 container will be the winner.
2) MPEG-1/2, because it is used in DVB-S and DVB-T broadcasting and will be used probably for a long time.
3) Support for speex - a low bitrate codec for speech is sometimes very useful

4) Support extracting VobSub files :p

E-Male
25th November 2004, 18:50
i'd like to second the request for speex support
it sure isn't a top priority, but it would be a really nice feature, for pure speech trax, like commentary or educational videos

Sirber
26th November 2004, 01:51
Having a crash with 1.0 :(

Tryed to mux VP6 (AVI) with HE-AAC (rmvb). Worked #1 with older version.

Don't worry and keep the good work :D

LeMoi
26th November 2004, 10:49
Could you make the progress bar bigger when you maximize the 'muxing' window ?

Mosu
26th November 2004, 17:33
Originally posted by LeMoi
Could you make the progress bar bigger when you maximize the 'muxing' window ?

Easy enough: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre//mkvtoolnix-1.0-build20041126-1.rar

Mosu
26th November 2004, 17:34
Originally posted by Sirber
Having a crash with 1.0 :(

Tryed to mux VP6 (AVI) with HE-AAC (rmvb). Worked #1 with older version.

Does it happen as well if you only mux one of the two at a time? Which "older" version was still working? Finally, can you upload the file that's causing the crash to my FTP server please?

Mosu
26th November 2004, 17:40
Originally posted by RedDwarf69
4) Support extracting VobSub files :p

I've had that wish on my TODO list (https://www.bunkus.org/anthill/query.php?bug=80) for quite some time now. Well, Alex Noé has kindly supplied me with some MPEG specs, but they're LONG, and I definitely lack the time to pursue this at the moment.

(Read: "Won't happen soon, but I don't rule it out completely.")

Mosu
26th November 2004, 17:42
Originally posted by E-Male
i'd like to second the request for speex support
it sure isn't a top priority, but it would be a really nice feature, for pure speech trax, like commentary or educational videos

I've been trying to find specs for Speex. Unfortunately there seems to be only an API reference, and that's definitely not what I need (I need file/bitstream specs). And #vorbis wasn't helpful so far either. I'll try the Speex devel ML soon. Again, I don't have that much time at the moment, and I'm already working on other aspects of mkvmerge (concatenating files, support for MPEG-1/-2). So don't expect anything soon.

Mosu
26th November 2004, 18:20
Originally posted by thana
just to clear up the confusion:

the way the windows worked in the original 1.0 release was already perfect!

Until the time I find/implement a real solution I just hide the main window during muxing. You can test this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre//mkvtoolnix-1.0-build20041126-2.rar

thana
26th November 2004, 18:45
Originally posted by Mosu
Until the time I find/implement a real solution I just hide the main window during muxing. You can test this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre//mkvtoolnix-1.0-build20041126-2.rar thanks, works good enough for me :)

Sirber
26th November 2004, 19:43
Originally posted by Mosu
Does it happen as well if you only mux one of the two at a time? Which "older" version was still working? Finally, can you upload the file that's causing the crash to my FTP server please? The latest 0.9x version was working well IIRC. The mux was AVI and RMVB at the same time. I will try to reproduce then send you the source. Can you PM me your FTP?

Mosu
26th November 2004, 19:45
Originally posted by Sirber
The latest 0.9x version was working well IIRC. The mux was AVI and RMVB at the same time. I will try to reproduce then send you the source. Can you PM me your FTP?

Look at my signature ;)

karl_lillevold
26th November 2004, 20:11
Just in case someone runs across the same problem I did: Once in a while an RM file can have the first audio packet at a time larger than zero, and in such cases the mkvmerged mkv will have audio out of sync. See this post for details.
http://forum.doom9.org/showthread.php?s=&threadid=85927
Mosu has already fixed the problem in a test build.

P.S. Congratulations on mkvtoolnix 1.0. Great work!

LeMoi
27th November 2004, 19:54
With the last version, when i mux, the window disappears from the taskbar, i just can call it by alt+tab :o, but the progress bar is nice, ;)

Mosu
28th November 2004, 19:05
Originally posted by LeMoi
With the last version, when i mux, the window disappears from the taskbar, i just can call it by alt+tab :o, but the progress bar is nice, ;)

Thana, LeMoi: next try: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre//mkvtoolnix-1.0-build20041128-1.rar It iconizes the main window before muxing (instead of "hiding" it) which keeps it in the taskbar here.

LeMoi
28th November 2004, 19:45
I guess the link must be this one :
http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-1.0-build20041128-1.rar

thanks, i'l try and tell you ;)

Mosu
28th November 2004, 19:55
Originally posted by LeMoi
I guess the link must be this one :
http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-1.0-build20041128-1.rar

thanks, i'l try and tell you ;)

Ups :) Of course. The usualy cut & paste problem :)

LeMoi
28th November 2004, 20:08
Hum, if i click on mux, the window minimizes itself and 'disappear' without i tell it to, but it's in the taskbar

Mosu
28th November 2004, 20:13
Originally posted by LeMoi
Hum, if i click on mux, the window minimizes itself and 'disappear' without i tell it to, but it's in the taskbar

Yes, that's intentional. Only the muxing window should be visible. I don't have time to implement a better fix at the moment because that would involve making the muxing dialogs non-modal and disabling all other controls...

LeMoi
28th November 2004, 20:20
I mean that the muxing window automatically minimizes, if i click on Star muxing, the desktop (or other applications opened before) appears ^^

hippoth
4th December 2004, 00:15
Hey Mosu,

at first a big THANKS for your great job! ;)

One question I have: In the releases before subtitles were shown by default. With your 1.0 release subtitles arenīt shown by default...thats not bad but sometimes when I have foreced subtiles it would be nice that I can set a flag (or something like this) to the subtitle that this is shown by default.
So, is it possible to make a checkbox that I can choose between showing ot not showing subtitles by default?

Mosu
4th December 2004, 10:56
Originally posted by hippoth
Hey Mosu,

at first a big THANKS for your great job! ;)

One question I have: In the releases before subtitles were shown by default. With your 1.0 release subtitles arenīt shown by default...thats not bad but sometimes when I have foreced subtiles it would be nice that I can set a flag (or something like this) to the subtitle that this is shown by default.
So, is it possible to make a checkbox that I can choose between showing ot not showing subtitles by default?

This has nothing to do with mkvmerge but with the playback application. Fact is that until recently TCMP interpreted the "default track" flag in the wrong way. "default track" does NOT force the player to display subtitles! It just gives a hint which track to select IF the user has turned on subtitle display.

We've only recently added a "forced display" flag. mkvmerge does not support that yet. And I as a user don't like being forced to watch subtitles. But as forced display stuff is used on DVDs as well we've included such a flag.

To make this clear: The question whether or not to show any subtitles at all should be an option in the playback application, not one of the container (safe for some special cases).

gfh
4th December 2004, 17:17
Sorry fom english.

I have a strange bug when I'm linking a video(xvid), audio(dts) with 0.5sec delay and subtitle(srt) with mmg.exe. When source files and output mkv in same catalog, then output is normal. When source and output in the different catalogs, then parameter delay is not working.

mkvtoolnix-1.0-build20041128-1.rar

Cyberman
4th December 2004, 22:25
Originally posted by Mosu
I'm not saying that mmg is total crap (who would say something like that about his own baby?), but it's pretty overloaded with functionality.
I wouldnīt say that - the required functions are quite clear, and the others are of no importance unless you need them - in which case you have to start looking into the manual anyway.

It doesn't have an online help
Thatīs a problem indeed. An online help would be a great addition, as it will make it easier for the occassional user.

Originally posted by Mosu
I don't think (and most of our Matroska team members agree) that this will not happen. Hardware players have very limited resources regarding memory and CPU power. Matroska on the other hand supports too many different codecs. A hardware vendor would have to support such a wide range of codecs, too, in order to be able to say "we support Matroska". Matroska's EBML basis is not the problem here -- the problem is that for some codecs like RealVideo there simply are no efficient and small decoders available.

Even if not all codecs are supported, some generic support of the container would be great.

DivX is supported by many HW player - but usually only in AVI. So youīre forced to create "hacked" files to play them on your DVD player.
Matroska is a good container that can use DivX natively - so itīd be the best trade-off, as you can use it on the PC and still could use it on HW players.

--

Do I need to say that MKVToolnix is great? ;-)

Mosu
4th December 2004, 22:40
Originally posted by Cyberman
I wouldnīt say that - the required functions are quite clear, and the others are of no importance unless you need them - in which case you have to start looking into the manual anyway.

Hmm. Yes. What I mean is that the most commonly used options could be grouped way better than they are now. mmg's tabs DO follow a logic, and knowing mkvmerge you'll figure out why I put the stuff where it is. But a really easy to use GUI could e.g. look like this:

1. First dialog asks you to add a couple of files. It lets you inspect the files (meaning it tells you how many tracks there are, the codecs used, duration of the file etc).
2. Then it lets you set only the most often used features which probably are track order, track language, file title, and maybe chapters.
3. Next step is to set the output file.
4. Now you have a final dialog which offers to save the settings, add it as a new job to the job queue, edit advanced features (all missing features except those in step 2) or finally start muxing.

But then again... I'm really no GUI usability guru. Maybe something else would be even better. As it is I won't implement something like that -- also because most of you feel quite comfortable with the current GUI.

This brings me to the next point:

Thatīs a problem indeed. An online help would be a great addition, as it will make it easier for the occassional user.

Yeah, I've thought about it, too. I will probably have to implement an online help. For that I could really use the help of someone who's good at writing easy-to-understand documentation. You know how well I do at that (just look at mmg's guide) ;)

I think I'll ask for help once I'm starting to work on that (definitely not this year anymore).

About hardware support:
Even if not all codecs are supported, some generic support of the container would be great.

Sure :) The most often asked question on the Matroska MLs is how to convert a file to something a DVD player can play. But for this feature to be really useful a player would probably have to support RealVideo and Vorbis, because those two are used very often, especially by Anime release groups. And RealVideo seems to be very low priority for HW vendors :(

Do I need to say that MKVToolnix is great? ;-)

Nope, but I love hearing it every single time :D

Cyberman
5th December 2004, 11:30
Originally posted by Mosu
1. First dialog asks you to add a couple of files. It lets you inspect the files (meaning it tells you how many tracks there are, the codecs used, duration of the file etc).
2. Then it lets you set only the most often used features which probably are track order, track language, file title, and maybe chapters.
3. Next step is to set the output file.

You do that and I guarantee I start using Quicktime. (Yeah, no big loss, I know.)
There is nothing worse than a know-it-all GUI that pretends to know what you want to do. Windows is the embodiment of that - hindering every second step.

The GUIs fine as it is, I say. Opening it, I can simply drag and drop files into it - no need to click around and search the file through the dialogue even though itīs right before me(in an open window).

Sure :) The most often asked question on the Matroska MLs is how to convert a file to something a DVD player can play. But for this feature to be really useful a player would probably have to support RealVideo and Vorbis, because those two are used very often, especially by Anime release groups. And RealVideo seems to be very low priority for HW vendors :(

Well, I see it this way:

Need to reencode to watch MKV on DVD Player: near 100%
Need to reencode with generic MKV support: about 80%
(Just a guess)

Even with AVI and Divx one canīt play all files - because even DivX support is restricted.

filewalker
5th December 2004, 12:07
1. First dialog asks you to add a couple of files. It lets you inspect the files (meaning it tells you how many tracks there are, the codecs used, duration of the file etc). 2. Then it lets you set only the most often used features which probably are track order, track language, file title, and maybe chapters. 3. Next step is to set the output file. 4. Now you have a final dialog which offers to save the settings, add it as a new job to the job queue, edit advanced features (all missing features except those in step 2) or finally start muxing.

I agree with Cyberman.

I also don't like such semi auotmatic GUIs.
I really like your current GUI as it is.
You can look around and can study all features which are possible.

Cu

Mosu
7th December 2004, 12:04
Okok, I get your point :) And best of all that's totally fine with me. No work for me, and you're happy as it is.

Mosu
7th December 2004, 12:22
Originally posted by gfh
Sorry fom english.

I have a strange bug when I'm linking a video(xvid), audio(dts) with 0.5sec delay and subtitle(srt) with mmg.exe. When source files and output mkv in same catalog, then output is normal. When source and output in the different catalogs, then parameter delay is not working.

mkvtoolnix-1.0-build20041128-1.rar

Do you mean "directory" instead of "catalog"? So when you mux

c:\videos\input.avi + c:\videos\input.wav --> c:\videos\output.mkv

then delay is working, but if you mux

c:\videos\input.avi + c:\videos\input.wav --> c:\somewhere\else\output.mkv

then delay is not working?

gfh
7th December 2004, 12:48
Originally posted by Mosu
Do you mean "directory" instead of "catalog"? So when you mux

c:\videos\input.avi + c:\videos\input.wav --> c:\videos\output.mkv

then delay is working, but if you mux

c:\videos\input.avi + c:\videos\input.wav --> c:\somewhere\else\output.mkv

then delay is not working?

Yes :)

Mosu
7th December 2004, 13:22
Ok, I'll see if I can reproduce it.

gfh
7th December 2004, 19:40
Originally posted by Mosu
Ok, I'll see if I can reproduce it.

I attempted mux another files and this work fine. But with file, that I mux before, it's repeated. Obviously it is a broken file(s) or aggregate of conditions: video XviD 2,2Gb (2200kb/s), audio DTS 630Mb(778kb/s) and subtitle in SRT format.

Cyberman
7th December 2004, 23:09
Originally posted by Mosu
Okok, I get your point :) And best of all that's totally fine with me. No work for me, and you're happy as it is.

Fine.

But, there IS something you could do. Something quite important for the survival of the GUI.

Give it an icon. The default windows "non-windows program" icon is ugly. Perhaps a variation of the Matroska Logo with a wrench to symbolize MatroskaTools.

LeMoi
7th December 2004, 23:30
Only one file may have an icon, the other ones are command tools : the mmg executable :D

Mosu
8th December 2004, 14:22
Originally posted by Cyberman
Fine.

But, there IS something you could do. Something quite important for the survival of the GUI.

Give it an icon. The default windows "non-windows program" icon is ugly. Perhaps a variation of the Matroska Logo with a wrench to symbolize MatroskaTools.

I know I know. I tried to get the application icon working back when I started with mmg but didn't succeed. Probably due to my limited GUI programming knowledge.

(Hey, that's actually a good excuse - me not having enough GUI programming knowledge. "mmg doesn't allow me to do xyz" - "That's because I can't program GUIs." or "mkvmerge crashes with a segfault :(" - "That's because I don't know much about GUI programming." or "My girlfriend just left me!" - "That's because I... Now wait a minute!")

I'll give it another try. I'll start with just the usual Matroska icon because I'm REALLY lost when it gets down to drawing nice little graphics (my artistic capabilities lie in music not in paintint/drawing). Maybe one of you mkvtoolnix users could create a nice mmg icon? :) I'd be happy to use it.

LeMoi
8th December 2004, 14:24
Just open a 'Matroska Icon contest' on customizing forums, you'll see the results :D

outlyer
8th December 2004, 22:09
@Mosu:
You can assign an icon to a top level window and IIRC (it's been ages since I touched wxWhatever) an icon can be loaded from an xpm even on windows.

jkwarras
9th December 2004, 12:14
Hi Mosu,

I have a request/suggestion, but I don't know if it can be done, but there you go ;)

Something I'll like to see implemented in mkvtoolnix is a mp3gain trackgain feature. I mean, consider a typical divx/mp3 where the mp3 audio file is too low or too high (broken sound). What I do it's pass it throw mp3gain and remux it to a mkv with mkvtoolnix. If it's was implemented inside mkvtoolnix it'll be great :)

For others audio formats (aac, ogg, etc...) I don't know anything similar to mp3gain apart replaygain, but this isn't supported by any video player that I know.

Thanks.

Mosu
9th December 2004, 12:35
Originally posted by outlyer
@Mosu:
You can assign an icon to a top level window and IIRC (it's been ages since I touched wxWhatever) an icon can be loaded from an xpm even on windows.

Yes, that is what I was struggling with. The wxWidgets docs say that wxWidgets can deal with XPM just fine on Windows, but for me it simply does not work. The same .xpm file loads fine on Linux but not on Windows (neither wxWidgets 2.4.2 nor 2.5.3 work...). So I converted the XPM to a native Windows .ico, loaded that and this seems to work: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre//mkvtoolnix-1.0-build20041209-12.rar

Mosu
9th December 2004, 12:39
Originally posted by jkwarras
Something I'll like to see implemented in mkvtoolnix is a mp3gain trackgain feature. I mean, consider a typical divx/mp3 where the mp3 audio file is too low or too high (broken sound). What I do it's pass it throw mp3gain and remux it to a mkv with mkvtoolnix. If it's was implemented inside mkvtoolnix it'll be great :)

Sorry, but the answer is no. I don't know much about mp3gain in general but calculating the peak volume probably requires decoding the MP3 data, and mkvmerge does not and will not contain any codecs. Same for Vorbis (there is vorbisgain which probably does what mp3gain does). For AAC it's even worse: normally even decoders need a license for which I would have to pay...

jkwarras
9th December 2004, 14:39
Originally posted by Mosu
Sorry, but the answer is no. I don't know much about mp3gain in general but calculating the peak volume probably requires decoding the MP3 data, and mkvmerge does not and will not contain any codecs.

Honestly I don't know anything about the way mp3gain (https://sourceforge.net/project/showfiles.php?group_id=49979) works internaly (decoding, etc... which seems logical anyway). It's based in replaygain (http://replaygain.org/) as it's wavgain and vorbisgain (http://www.sjeng.org/vorbisgain.html).

AFAIK, the best replaygain tool I've ever seen is foobar replaygain which support almost any format, but the downside is that the fb2k implementation writes the info as metadata and not actually as id3v2 tags as mp3gain does, so it's not supported anywhere but in foobar. The way that mp3gain does is storing the info in a id3v2 tag, that's supported by any audioplayer I know (i.e. media player classic). Please, someone correct me if I'm wrong.

But if implementing this means that you have to include codec support, blabla and licencing issues or simply doing stuff you didn't intend to, then I understand completely ;)

Thanks.

thana
9th December 2004, 14:59
Originally posted by jkwarras
AFAIK, the best replaygain tool I've ever seen is foobar replaygain which support almost any format, but the downside is that the fb2k implementation writes the info as metadata and not actually as id3v2 tags as mp3gain does, so it's not supported anywhere but in foobar. The way that mp3gain does is storing the info in a id3v2 tag, that's supported by any audioplayer I know (i.e. media player classic). Please, someone correct me if I'm wrong.

that's not exactly correct. replaygain and mp3gain are two fundamentally different ways of applying the gain, only the algorithm for calculating the correct volume should be the same.

replaygain adds the calculated values in a proprietary tag to the mp3, but otherwise doesn't change anything. players with replaygain support read this tag and apply it on the fly on playback. and there are some other players besides foobar which can do this, there is even a winamp plugin with replaygain support.

mp3gain applies the calculated values directly to the mp3 in a lossless process, and because of this every mp3-decoder automatically uses the new volume, even without idv1/idv2 or any other tag.
mp3gain additionally stores the original values in an ape-tag in the mp3, so that you can (lossless) reverse the gaining at a later time if you want to, but this is not necessary for correct playback.

in either way you have to decode the mp3 beforehand for finding the peak and average volume, so it's no option for mkvtoolnix it seems.

jkwarras
9th December 2004, 16:03
Originally posted by thana
that's not exactly correct. replaygain and mp3gain are two fundamentally different ways of applying the gain, only the algorithm for calculating the correct volume should be the same.

Thanks for the info thana, it's always cool to learn something everyday :)

in either way you have to decode the mp3 beforehand for finding the peak and average volume, so it's no option for mkvtoolnix it seems.

:( Well, I'll live with that :D

r0cket
10th December 2004, 09:53
I don't even need any icons. But Mosu, please make an mmg's window position saving or make it always appear at 0,0.

Mosu
10th December 2004, 15:44
Originally posted by r0cket
I don't even need any icons. But Mosu, please make an mmg's window position saving or make it always appear at 0,0.

Does this build help you? http://www.bunkus.org/videotools/mkvtoolnix/win32/pre//mkvtoolnix-1.0-build20041210-1.rar

iradic
11th December 2004, 01:34
hi
did you ever try mkvtoolnix at 800x600 res?

some improvements would be nice...

thanks, bye

r0cket
11th December 2004, 07:24
Originally posted by Mosu
Does this build help you?
Yep. Thanks :)

niamh
11th December 2004, 20:41
A belated BIG thank you for mkvtoolnix 1.0, after 2 months of offline hell ;) I haven't been able to try it yet, but I can't wait to.

This is the "manual" icon me and a friend have been using for ages, and doesn't it look cool? :D:D (but nice to be rid of the generic white square, at long last :))

http://img121.exs.cx/img121/4724/image10wp.jpg

outlyer
11th December 2004, 22:08
Originally posted by niamh
This is the "manual" icon me and a friend have been using for ages, and doesn't it look cool? LOL. Quite cool, I guess Mosu will like it :)

jkwarras
12th December 2004, 16:34
Hi Mosu,

Any chances of getting .mht attachments auto-recognized as text/html mime/type?

Thanks in advance.

pixolex
12th December 2004, 23:25
Originally posted by niamh
A belated BIG thank you for mkvtoolnix 1.0, after 2 months of offline hell ;) I haven't been able to try it yet, but I can't wait to.

This is the "manual" icon me and a friend have been using for ages, and doesn't it look cool? :D:D (but nice to be rid of the generic white square, at long last :))

http://img121.exs.cx/img121/4724/image10wp.jpg

I VOTE for that Icon :D

mikeX
13th December 2004, 05:01
first off congratulations Mosu, mkvtoolnix is a great and useful (at least for me ;)) tool.

i've noticed a little problem, which is more of a nuissance than a real bug (sorry if it's been mentioned before but it's hard to search for it). It only happens on linux and it has to do with mmg (no particular version):

while muxing a file, the 'ok' button of the file is greyed out. If you click it as soon as it becomes available, mmg segfaults.

"as soon as it becomes available" means inbetween the time where 'Status & progress' says "Muxing in progress" and 'Ok' is available and 'Status & progress' says "mkvmerge finished with a return code of 0. Everything went fine.". Sure it's a very short amount of time, but it was long enough for me to notice ;P.

i can't reproduce it on windows ("mkvmerge finished ..." and 'Ok' becoming available seem instantaneous there).

the resulting file seems ok [mkvmerge is unaffected]

i have libwxgtk-2.4.2.6, mkvtoolnix versions are from your debian builds.

just thought i'd let you know, it's not a real/serious problem anyway...

hope you keep up the good work ; )

Mosu
14th December 2004, 15:42
Originally posted by iradic
hi
did you ever try mkvtoolnix at 800x600 res?

Yes.

some improvements would be nice...

Won't happen. mmg is usable in 800x600 if you move the lower end out of the screen. Everthing up to and including the output file name text box should be visible.

Sorry, but users with 800x600 are not important enough for me to completely rework the GUI. Also I cannot simply reduce the space between controls because on Linux the GTK based wxWidgets tend to create VERY large controls, and they barely fit into the GUI at the moment.

Mosu
14th December 2004, 15:44
Originally posted by niamh
This is the "manual" icon me and a friend have been using for ages, and doesn't it look cool? :D:D (but nice to be rid of the generic white square, at long last :))

http://img121.exs.cx/img121/4724/image10wp.jpg

Now where do I know THIS icon from? :D Definitely one of my favourites. How did you guess? :)

But I should probably stick to a more "official" and "Matroska-ish" logo.

Mosu
14th December 2004, 15:45
Originally posted by jkwarras
Hi Mosu,

Any chances of getting .mht attachments auto-recognized as text/html mime/type?

Thanks in advance.

Sure, easy enough, will be in 1.0.2.

Mosu
14th December 2004, 15:46
Originally posted by mikeX
while muxing a file, the 'ok' button of the file is greyed out. If you click it as soon as it becomes available, mmg segfaults.

Yes, I've noticed that as well. Time to do something about it...

Mosu
14th December 2004, 15:57
Hey,

maybe you've noticed it already: I've released v1.0.1 yesterday evening. It's really only a bug fix release with a couple of minor annoyances (nothing major). The usual links:

...to the homepage:
http://www.bunkus.org/videotools/mkvtoolnix/
...the source code:
http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-1.0.1.tar.bz2
...the Windows binaries:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-1.0.1.rar

Binaries for SuSE and Fedora Core are available from the homepage.

Here's the ChangeLog since 1.0:
---------------------------------------------
2004-12-13 Moritz Bunkus <moritz@bunkus.org>
* Released v1.0.1.

2004-12-11 Moritz Bunkus <moritz@bunkus.org>
* mmg: Fixed some layout issues with wxWidgets 2.5.3 and newer.

2004-12-10 Moritz Bunkus <moritz@bunkus.org>
* mmg: new feature: The window position is saved and restored when mmg is started the next time.

2004-12-09 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Fixed a crash/memory corruption showing weird characters in the input boxes. This happened when the user removed a file from mmg while mmg was updating the command line.
* mmg: bug fix: mmg now has an icon associated with it while it is running instead of the generic Windows application icon (Windows only).
* mmg: bug fix: The main window is now minimized during muxing. This allows to hide both of the windows while muxing is running and restoring them later, even if they were iconized when muxing finished (Windows only).

2004-11-26 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: The first packet of an AAC track read from Real containers might not start at the timecode 0. This offset was ignored by mkvmerge.

2004-11-22 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Made the muxing dialog ("mkvmerge is running") modal all the time. This prevents the user from hitting the main window's minimize button. On Windows this makes mmg stuck in iconized mode if it was iconized when muxing finished.

2004-11-20 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed a buffer overflow in the UTF-8 file reading routines.
------------------------------------

Have fun :)

jkwarras
14th December 2004, 16:15
Originally posted by Mosu
Sure, easy enough, will be in 1.0.2.
Thanks :)

Nic
14th December 2004, 16:51
Hi Mosu,

I'm having trouble with mkvmerge, but it may just be my lack of understanding of the commandline (although I have tried the GUI as well)

(I've uploaded the files below to your FTP in a directory called Nic)

I'm trying to do:
mkvmerge.exe -o C:\BLACKBOOKS\wow34.mkv C:\BLACKBOOKS\wow3_NoSound.avi -y 0:-240 C:\BLACKBOOKS\wow3_-240ms.mp3

To mux the mp3 and avi together with an audio delay of -240ms. However, when I attempt this, the file cannot be played back with audio (the video works but the audio is silent (tested with MPC and VideoLan))

Smaller delay values (such as -5, etc) appear to work (although I can't tell if it's actually being delayed...that might be a feature to display in mkvinfo (in the future perhaps :) ))

What do you reckon? Am I doing something wrong?

Thanks for any guidance,
-Nic

ps
I'm using the mkvmerge from your last post in this thread (v1.0.1)

Mosu
14th December 2004, 23:15
Originally posted by mikeX
while muxing a file, the 'ok' button of the file is greyed out. If you click it as soon as it becomes available, mmg segfaults.

I'm not sure why it crashes (ok I do have an idea), but you can test the attached patch. It seems to work better for me with the patch.

(I guess the patch has to be approved by a moderator)

Mosu
14th December 2004, 23:37
Originally posted by Nic
I'm trying to do:
mkvmerge.exe -o C:\BLACKBOOKS\wow34.mkv C:\BLACKBOOKS\wow3_NoSound.avi -y 0:-240 C:\BLACKBOOKS\wow3_-240ms.mp3

Just wanted to give you some feedback: The command line looks perfectly fine. I'll check the files you've uploaded tomorrow (I hope).

Yong
15th December 2004, 12:19
Thank you Mosu,
This is a great software.:)

But i have a question,
why the mkvtoolnix doesn't support ASF/WMV container?

Mosu
15th December 2004, 12:30
Originally posted by Yong
But i have a question,
why the mkvtoolnix doesn't support ASF/WMV container?

Because Microsoft has some patents on those and has proven in the past to come after OpenSource projects (VDubMod) that implement ASF.

Yong
15th December 2004, 12:42
Sorry for asking this,
although i can do that with graphedit + mkvmuxer,

Thanks to make me clear.;)

Atamido
15th December 2004, 15:08
I have used GraphEdit to mux WMV to MKV several times. It depends largely on what is in the WMV and what version of GraphEdit you have. Earlier versions don't work well.

I have this version:
5.04.00.2904 - Build: 040709

Edit: I just realized that you said "can" instead of "can't". Please disregard.

Mosu
15th December 2004, 19:36
Originally posted by Nic
I'm trying to do:
mkvmerge.exe -o C:\BLACKBOOKS\wow34.mkv C:\BLACKBOOKS\wow3_NoSound.avi -y 0:-240 C:\BLACKBOOKS\wow3_-240ms.mp3

There was definitely a bug in how mkvmerge handled negative audio sync for MP3 for short files. I'm not sure if your problem is the same that I've tried to fix. Please test this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre//mkvtoolnix-1.0.1-build20041215-1.rar

Thanks.

mikeX
16th December 2004, 22:57
the patch appears to work fine (tested on 2 pcs, debian sid/sarge)

; )

jk888
18th December 2004, 19:16
The labels for vobsubs don't show up correctly when I look at the filters or right-clicking the arrow icon on the tasktray. If I have 3 subs all different language, all three labels will show up but they are named only after the first sub. For example, 3 subs, 1. English, 2. Chinese, 3. Japanese. All 3 labels show up but all are called English.

This appeared around the 0.90 builds and exist even in the latest 1.01 build. Noticed it for a long time but always too lazy to report it. I'm using the Windows 2000 platform.

Mosu
18th December 2004, 19:22
Originally posted by jk888
The labels for vobsubs don't show up correctly when I look at the filters or right-clicking the arrow icon on the tasktray. If I have 3 subs all different language, all three labels will show up but they are named only after the first sub. For example, 3 subs, 1. English, 2. Chinese, 3. Japanese. All 3 labels show up but all are called English.

This appeared around the 0.90 builds and exist even in the latest 1.01 build. Noticed it for a long time but always too lazy to report it. I'm using the Windows 2000 platform.

That has honestly nothing to do with mkvtoolnix and seems to be a VSFilter bug (I guess that you're talking about VSFilter, right?).

Mosu
18th December 2004, 19:37
Hey,

1.0.1 had the unfortunate habit of minimizing the main window. This did allow hiding mmg completely during muxing, but the muxing window was pushed into the back. And that's pretty confusing.

So I've tried some other solutions. Please test this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-1.0.1-build20041218-1.rar

Thanks.

LeMoi
18th December 2004, 20:33
I told you about this 'bug' before but you didn't understand me :p
And now,it seems to be fixed : when you mux, mmg window is still there in backrgound, and if you minimize the muxing window, mmg window reappears and can be minimzed too

Omni
19th December 2004, 05:00
any chance to mux neros mp4 (avc video) files into mkv this year? :)
but well i can just say: matroska rocks! keep on your good work!

jk888
19th December 2004, 09:02
Originally posted by Mosu
That has honestly nothing to do with mkvtoolnix and seems to be a VSFilter bug (I guess that you're talking about VSFilter, right?).

Bummer, who makes VSFilter? I'd like to let him know.

Mosu
19th December 2004, 09:33
Originally posted by Omni
any chance to mux neros mp4 (avc video) files into mkv this year? :)
but well i can just say: matroska rocks! keep on your good work!

Muxing already works, playback has some issues, won't be finished this year.

Mosu
19th December 2004, 09:34
Originally posted by jk888
Bummer, who makes VSFilter? I'd like to let him know.

Gabest, but I he doesn't have all that much time anymore. I've also shown your post to Toff & Haali, maybe they can do something about it.

[Toff]
19th December 2004, 10:46
Originally posted by jk888
The labels for vobsubs don't show up correctly when I look at the filters or right-clicking the arrow icon on the tasktray. If I have 3 subs all different language, all three labels will show up but they are named only after the first sub. For example, 3 subs, 1. English, 2. Chinese, 3. Japanese. All 3 labels show up but all are called English.

This appeared around the 0.90 builds and exist even in the latest 1.01 build. Noticed it for a long time but always too lazy to report it. I'm using the Windows 2000 platform.

What splitter are you using ?
Can you try the last MatroskaSplitter version available here :
http://sourceforge.net/project/showfiles.php?group_id=82303&package_id=84361&release_id=260939

And also last vsfilter available here :
http://sourceforge.net/project/showfiles.php?group_id=82303&package_id=84359&release_id=222162

If the problem still occur can you upload the first 2MB of your file somewhere ?

Omni
19th December 2004, 14:25
is the playback problem caused due to bad muxikng or due to splitter/palyback filter issues?
if i try to mux a nero generated mp4 file into mkv the following warning messages is printed:
Warning: Quicktime/MP4 reader: Unknown/unsupported FourCC 'avc1' for track 3.

Mosu
19th December 2004, 14:28
Originally posted by Omni
is the playback problem caused due to bad muxikng or due to splitter/palyback filter issues?

Playback problems because Nero's decoder totally ignores the DirectShow timestamps and only uses the FPS provided to him via DirectShow.

if i try to mux a nero generated mp4 file into mkv the following warning messages is printed:
Warning: Quicktime/MP4 reader: Unknown/unsupported FourCC 'avc1' for track 3.

That's because 1.0.1 doesn't support it.

Omni
19th December 2004, 14:31
well i thought it works now since you wrote:
> Muxing already works, playback has some issues, won't be finished this year.

okay when does it work then? *g* (ignoring the decoder problem)

Mosu
19th December 2004, 14:32
Originally posted by Omni
well i thought it works now since you wrote:
> Muxing already works, playback has some issues, won't be finished this year.

okay when does it work then? *g* (ignoring the decoder problem)

It works in the developper version which has not been released yet and which will not be released this year. Maybe (!!) in January. That's a VERY big "maybe".

Omni
19th December 2004, 14:37
ahhh okay :)
well can't wait to see a working matroska file containing h264 content :)
thanks for the info.

jk888
20th December 2004, 19:29
Originally posted by Mosu
Gabest, but I he doesn't have all that much time anymore. I've also shown your post to Toff & Haali, maybe they can do something about it.

If it's made by Gabest then it should be an old ancient version that hasn't changed for over a year. This bug only showed up a few months ago. Everything was fine previously, then sometime after the 0.9 builds of mkvtoolnix the bug started.

Mosu
20th December 2004, 19:58
Originally posted by jk888
If it's made by Gabest then it should be an old ancient version that hasn't changed for over a year. This bug only showed up a few months ago. Everything was fine previously, then sometime after the 0.9 builds of mkvtoolnix the bug started.

Please have a look at Toff's response to your first post above. Thanks.

jk888
23rd December 2004, 17:04
Originally posted by [Toff]
What splitter are you using ?
Can you try the last MatroskaSplitter version available here :
http://sourceforge.net/project/showfiles.php?group_id=82303&package_id=84361&release_id=260939

And also last vsfilter available here :
http://sourceforge.net/project/showfiles.php?group_id=82303&package_id=84359&release_id=222162

If the problem still occur can you upload the first 2MB of your file somewhere ?

Yes I have all the lastest filters, they were released in Matroska Pack 1.03.

The problem is with mkvtoolnix, because i have 2 mkvs to prove it, one I had encoded few month ago, the sub labels show up correctly even when I play them today. All the new ones I encode and mux with mkvtoolnix has the incorrect sub labels. The old one I muxed using mkvtoolnix v0.86.

I don't think I can upload a segment, because currently there's no program to cut out a specific segment of an encoded mkv. Unless you want the whole movie all 700mb.

[Toff]
24th December 2004, 08:03
Originally posted by jk888
I don't think I can upload a segment, because currently there's no program to cut out a specific segment of an encoded mkv. Unless you want the whole movie all 700mb.

Just stop the upload when you have uploaded 2 MB.
Or use any program that can split file.
For example VirtualDub Hex Editor (Main meun>Tools>Hex Editor) can do that.

jk888
26th December 2004, 19:08
Ok I uploaded a small segment of the 2 videos, sorry I went over the 2mb limit slighty.

The video clip "Old Boy" is the good clip, where all the sub labels show up correctly. It was muxed using an old version of mkvtoolnix, probably version 0.86.

The one called "Casshern" has the incorrect labels. For some reason the only labels that show up are English and Japanese; but there are 4 labels, they should be English, Traditional Chinese, Simplified Chinese, Japanese. This video and others I made for months already are like that, having incorrect sub labels. This one has been muxed using the latest version of mkvtoolnix.

Mosu
26th December 2004, 22:58
Toff: I've uploaded the two files that jk888 uploaded here: http://www.bunkus.org/videotools/mkvtoolnix/temp/jk888_subs_label_problem/index.php

jk888: So far I can "only" see a couple of new elements that are present in the new files, but every demuxer SHOULD simply skip unknown elements. Anyway, I hope Toff will be able to figure out what goes down the drain here.

Sirber
29th December 2004, 18:30
What does the exitCode #2 mean?

Mosu
29th December 2004, 18:37
Originally posted by Sirber
What does the exitCode #2 mean?

Exit codes:

0 = everything was fine,
1 = there were warnings (starting with "Warning:" on the command line, output into the middle text box in mmg),
2 = there were errors (starting with "Error:" on the command line, output into the lower text box in mmg).

An "error" means that the program will be terminated right after the error is output. There can be various reasons for errors -- invalid command line parameters, broken files...

Sirber
29th December 2004, 19:03
k, thanks :D

Dima
6th January 2005, 20:28
Just one question. What does "link files" means? Must player automatically load next segment (file) after first ends (if it's so - what player can do that). Or linking only for showing full time (first + second file) during playback of second file?
Then why does timeline in players during playback of second file starts from 0 (but not from the end of first file).
I think it's must be like that: for example first file shows 0...40 min, second file shows 40...120 min (but not 0...120min).
Thanks.

Mosu
6th January 2005, 20:33
Originally posted by Dima
Just one question. What does "link files" means? Must player automatically load next segment (file) after first ends (if it's so - what player can do that).

That was the idea back when the feature was introduced, but there is no player that supports this feature. Therefore you should just avoid using it.

outlyer
6th January 2005, 21:29
it's sad that such a nice feature didn't get implemented :(

pixolex
7th January 2005, 15:50
Originally posted by outlyer
it's sad that such a nice feature didn't get implemented :(
we are young and patient, we'll wait for the return of Gabest...:(

Mosu
7th January 2005, 15:52
Originally posted by pixolex
we are young and patient, we'll wait for the return of Gabest...:(

I doubt that he'll return. That's why we're so happy that Haali's actively working on a very good splitter.

filewalker
7th January 2005, 16:41
I doubt that he'll return.
Out of curiosity...do you know more, job, health,...?
It makes me feel sad to read such words. :( ...it would be a loss for the whole community....



Cu

Mosu
7th January 2005, 16:46
Originally posted by filewalker

Out of curiosity...do you know more, job, health,...?
It makes me feel sad to read such words. :( ...it would be a loss for the whole community....



Cu

Nope, I have no clue about him. I guess job / real life / significant other, the usual things. I just know that after spending a LOT of time on IRC in #matroska he suddenly disappeared 1 1/4 years ago. After that he only reacted sporadically to emails, bug reports, feature requests.

LeMoi
7th January 2005, 16:53
I heard that he was working for MS and that he has absolutely no time for these stuff :o

sterlina
7th January 2005, 19:48
Originally posted by Dima
Just one question. What does "link files" means? Must player automatically load next segment (file) after first ends (if it's so - what player can do that). Or linking only for showing full time (first + second file) during playback of second file?
Then why does timeline in players during playback of second file starts from 0 (but not from the end of first file).
I think it's must be like that: for example first file shows 0...40 min, second file shows 40...120 min (but not 0...120min).
Thanks. that would be great, but it actually doesn't work because of the splitter. Haali's splitter work better - I've done a little test here http://forum.doom9.org/showthread.php?s=&postid=579180#post579180. (about it: the idea was to do more than one test, with different video/audio resolution... just got no time).

[OT] about Gabest: don't know anything about his new job, but I see that his cvs on sourceforge is sometime updated... so as everybody I hope he to come back soon

jk888
9th January 2005, 12:11
I tried to mux Nero AVC, Nero AAC-HE, and vobsubs using mkvtoolnix. Sadly it crashed. I was using the latest mkvtoolnix dated Jan 7th 2005. Does anyone know when we will get Nero AVC in mkv?

Mosu
9th January 2005, 12:13
Originally posted by jk888
I tried to mux Nero AVC, Nero AAC-HE, and vobsubs using mkvtoolnix. Sadly it crashed. I was using the latest mkvtoolnix dated Jan 7th 2005. Does anyone know when we will get Nero AVC in mkv?

Could you perhaps upload that file so that I can fix the crash? For me AVC is already working (even playback with mplayer), but I'm not sure about the status of playback on Windows. Have to ask Haali.

jk888
9th January 2005, 12:18
sorry which file do you want? The Nero AVC, or the log file? Because I can't even produce the mkv yet, mkvtoolnix crashes during muxing not playback.

If you want the AVC I take it you just want me to upload 2mb then stop the upload right?

Mosu
9th January 2005, 12:26
Originally posted by jk888
sorry which file do you want? The Nero AVC, or the log file? Because I can't even produce the mkv yet, mkvtoolnix crashes during muxing not playback.

If you want the AVC I take it you just want me to upload 2mb then stop the upload right?

I want the AVC file so that I can reproduce the crash and fix it. When does it crahs? Right at the beginning? If so, then 2mb should be enough. If not then I'll shout :)

jk888
9th January 2005, 12:44
not right away but a few secs into the muxing. Mkvtoolnix seems to mux in the AAC-HE first, the resulting file produced is unplayable but the file size is the same as my source AAC file.

I'll upload my AVC now, thx Mosu for looking into this.

jk888
9th January 2005, 12:56
Hi Mosu, something wrong with your DNS? can't resolve the no-ip DNS.


edit:
sorry my mistake, everything working now.

Mosu
9th January 2005, 13:13
Originally posted by jk888
Hi Mosu, something wrong with your DNS? can't resolve the no-ip DNS.

I can resolve it just fine. Anyway, my current IP is 212.202.182.236

jk888
9th January 2005, 14:42
Ok I'm done uploading, sorry once again I went over the 2mb limit... 50mb this time. My FTP client only shows the % uploaded but not the bytes...

Atamido
10th January 2005, 05:48
Originally posted by filewalker
Out of curiosity...do you know more, job, health,...?I think the last I heard about Gabest was this girl...

[Toff]
11th January 2005, 22:17
Originally posted by jk888
Ok I uploaded a small segment of the 2 videos, sorry I went over the 2mb limit slighty.

The video clip "Old Boy" is the good clip, where all the sub labels show up correctly. It was muxed using an old version of mkvtoolnix, probably version 0.86.

The one called "Casshern" has the incorrect labels. For some reason the only labels that show up are English and Japanese; but there are 4 labels, they should be English, Traditional Chinese, Simplified Chinese, Japanese. This video and others I made for months already are like that, having incorrect sub labels. This one has been muxed using the latest version of mkvtoolnix.

The good news is your file are really OK.
The bad one is that there is a bug in the language decoding (iso639-2 -> language name) of both MatroskaSplitter and VSFilter.
The difference between this 2 files is that, "Old Boy" use "chi" as iso639-2 code for "Chinese", and "Casshern" use "zho".
"chi" works well but not "zho" in current MatroskaSplitter/VSFilter.

You can find some hopefully fixed version here :
http://www.matroska.org/~toff/MatroskaSplitter_20050111.rar
http://www.matroska.org/~toff/VSFilter_20050111.rar

jk888
12th January 2005, 16:17
Yes it's working now! Thx alot, then all we need is an updated Matroska Packs. Then we're all set.

Mosu
12th January 2005, 16:33
Originally posted by jk888
Ok I'm done uploading, sorry once again I went over the 2mb limit... 50mb this time. My FTP client only shows the % uploaded but not the bytes...

That's quite OK. Unfortunately that file does not help me at all because its headers are at the end (which is perfectly OK for Quicktime/MP4 files). This means that mkvmerge cannot deal with that file at all unless you upload it completely. So if you've got some bandwidth to spare -- I definitely have enough HDD space ;)

BTW: A lot of FTP clients support resuming an upload.

jk888
12th January 2005, 16:41
One more thing I'm wondering if the Matroska team can fix, I know it's not your project but Gabest is gone now so this bug might never get fixed...

The Media Player Classic has an option to turn off auto-sub loading, it's in the player options -> playback section, but it doesn't work. When I play a mkv file with vobsubs muxed into it, MPC will load the sub, and VSFilter will also load it. So I end up having double subs showing up on the screen. The VSFilter is the best choice because we continue to update it, so if we can disable the MPC auto-sub load then it will really help end-users out.

jk888
12th January 2005, 16:46
Originally posted by Mosu
That's quite OK. Unfortunately that file does not help me at all because its headers are at the end (which is perfectly OK for Quicktime/MP4 files). This means that mkvmerge cannot deal with that file at all unless you upload it completely. So if you've got some bandwidth to spare -- I definitely have enough HDD space ;)

BTW: A lot of FTP clients support resuming an upload.

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.

Mosu
12th January 2005, 16:48
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
12th January 2005, 18:04
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
14th January 2005, 17:40
Hi Mosu, uploaded completed, you have the entire AVC file now. I look forward for a fix.

compunerd632
14th January 2005, 23:29
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
14th January 2005, 23:36
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
15th January 2005, 00:13
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
15th January 2005, 17:15
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
15th January 2005, 18:11
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
15th January 2005, 18:26
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
15th January 2005, 19:09
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
15th January 2005, 22:30
@ 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
15th January 2005, 23:03
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
15th January 2005, 23:21
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
15th January 2005, 23:22
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
16th January 2005, 00:01
Thank Mosu for answering.
I will be waiting for new builds:)

Mosu
16th January 2005, 00:02
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
16th January 2005, 00:09
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
16th January 2005, 00:12
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
16th January 2005, 18:28
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
16th January 2005, 21:01
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
16th January 2005, 21:10
Never mind, its an FFDshow issue as nero digitals video decoder decodes at the correct fps.

frodoontop
17th January 2005, 11:56
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
17th January 2005, 12:14
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
18th January 2005, 23:44
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
21st January 2005, 03:00
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
21st January 2005, 09:21
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
24th January 2005, 11:42
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
25th January 2005, 13:52
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
25th January 2005, 14:09
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
25th January 2005, 14:37
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
25th January 2005, 16:10
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
25th January 2005, 16:21
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
25th January 2005, 16:59
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
25th January 2005, 17:39
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
25th January 2005, 17:51
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
25th January 2005, 18:07
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
25th January 2005, 22:53
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
27th January 2005, 00:56
@ 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
29th January 2005, 03:50
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
29th January 2005, 09:37
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
30th January 2005, 16:14
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
30th January 2005, 16:30
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
30th January 2005, 18:14
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
30th January 2005, 18:26
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
30th January 2005, 18:33
Originally posted by Shinobu
8mo sample is it ok for you ?
if it's ok i'll start upload ^^

Sure. Go ahead :)

Shinobu
30th January 2005, 18:42
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
30th January 2005, 18:46
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
30th January 2005, 18:56
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
30th January 2005, 18:59
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
30th January 2005, 19:02
@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 ^^

++

kurt
30th January 2005, 19:21
Shinobu, it works with the version you posted (01/01/05)! playback is fine now with ffdshow ...

Mosu
30th January 2005, 19:23
Which ffdshow version are you guys using? (the exact version/date, please, not just "the latest one")

JasonFly
30th January 2005, 19:27
Tested with the 17/01/2005 from celtic druid

I am going to try with a more recent build. I thougth I had installed one but I didn't... More info in a few minutes

EDIT: With the 22/01/2005 build, file is choppy too.

kurt
30th January 2005, 19:33
Originally posted by JasonFly
EDIT: With the 22/01/2005 build, file is choppy too.
jep, i'm using this version too ...

Shinobu
30th January 2005, 19:44
tried different ffdshow, its all the same bug.
but one thing is sure, with the mmg 01/01/2005 it's not choppy, with newer it's choppy, seems that for kurt it's the same...

++

JasonFly
30th January 2005, 19:50
The effect is also present in small clip of 5 Mb.

I must also add that subs are flickering/blinking, i don't know what word best describe the phenomenon.

I must admit that one some scenes, this "choppiness" is very subtle but when you watch the original and the choppy ckip, the difference is clear.

Mosu
30th January 2005, 20:29
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,

I've fixed this...

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

...and hopefully this as well. I've tested it, and it works fine here on both Windows & Linux (meaning I haven't been able to create chapter entries with an empty language). Before you could also select one of the "separator" entries ("---common---"). This is checked in verify as well.

Could you please download http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/HEAD//mkvtoolnix-head-20050130-1.rar and give it a try?

Thanks.

"verify" doesn't seem to find problems before saving.

Just for your information: That verify function is called automatically before each call to "save", "save as" or "save to Matroska file". That there's an extra menu option for it is meant mainly as a tool for myself. But users might want to check the validity of their entries as well (e.g. having forgotten to enter a start time).
the resulting xml contains an empty tag, f.e. "<ChapterLanguage></ChapterLanguage>", and mmg refuses to load it again.

Mosu
30th January 2005, 20:44
Originally posted by Shinobu
tried different ffdshow, its all the same bug.
but one thing is sure, with the mmg 01/01/2005 it's not choppy, with newer it's choppy, seems that for kurt it's the same...

++

Thanks for the uploads, but I'm really confused at the moment. You've uploaded two files, "ok.mkv" and "chopy.mkv". Looking at the file headers tells me that "ok.mkv" was muxed with a build from "Jan 1 2005 20:52:36" while "chopy.mkv" was muxed with a build from "Dec 21 2004 19:30:47". Perhaps you mixed something up here? Because apart from these headers the two files are actually byte-identical.

Please retry at least with http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/HEAD/mkvtoolnix-head-20050125-1.rar (this version writes "Jan 22 2005 17:00:16" as the build date) or, even better, with today's build http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/HEAD/mkvtoolnix-head-20050130-1.rar (this version writes "Jan 30 2005 20:21:51" as the build date).

Thanks.

JasonFly
30th January 2005, 21:01
I 've upload asample.

Some more info:
While playing the choppy clip with ffdshow OSD on, fps is fluctuating:
62.50
0.00
12.50
12.82
66.67
15.87

I hope that'll help

EDIT:
Seems that I misundertood the concept behind "decoding FPS" in ffdshow. I didn't notice that it wasn't related to FPS(24,25,23.996...usually) but to the decoding speed. Sorry for this.

Koti
31st January 2005, 00:18
originaly posted by Shinobu
could you try the build i post (01/01/2005) and tell me if it's produice no-choppy mkv for you too.

It worked for me as well - perfect playback with ffdshow

Every other nero avc I ever muxed to mkv (various versions of ffdshow , halli's mkv splitter , mmg ) has been choppy with flashing subs and 0-62 fps decoding.

edit - also tried todays build of mmg (20050130-1.rar). choppy file :(

Mosu
31st January 2005, 08:17
If you all want a technical explanation of what's going on:

MP4 files can contain an atom named CTTS. Especially for AVC/h.264 video tracks. This atom maps the timecodes usually found in a MP4 file to display timecodes. Normally, the timecodes are 0ms, 40ms, 80ms, 120ms... etc. for a 25 FPS file. With a CTTS atom these can become e.g. 0ms, 120ms, 40ms, 80ms... This is also the case for B frames in "normal" MPEG-4.

Up until early this year (I don't know the exact date, but let's say January 10th or so) mkvmerge did not evaluate the CTTS atom at all. So the build from 20050101 simply uses the ordered timecodes. ffdshow seems to be happy with those.

Unfortunately, Nero's decoder is NOT happy with those timestamps. It sees ordered timecodes, but it derives from the frame data itself that those are wrong and falls back to a fixed FPS mode. This is not what we want.

Therefore the Matroska team (more like Haali and me) decided to do it the "right" way and to store display timecodes. This is "right" because Matroska does indeed store display timecodes. This is also true for what I call "native MPEG-4 storage" or "native B frames".

Unfortunately ffdshow does not seem to be happy with those timecodes. We're not sure what we will do about that, but it seems that it is an issue on the decoder side and not one on mkvmerge's side. I guess Haali will try to contact Milan (the ffdshow developper). But judging from the past he may not be the quickest to respond.

Koti
31st January 2005, 16:17
Thanks for the explanation and for looking into this. :)

kurt
31st January 2005, 23:46
so in the meantime we shouldn't use mkvtoolnix from 01/01/05 (cause of unstable playback with nerodecoder) and wait for newer ffdshow-versions?

Mosu
1st February 2005, 00:23
Originally posted by kurt
so in the meantime we shouldn't use mkvtoolnix from 01/01/05 (cause of unstable playback with nerodecoder) and wait for newer ffdshow-versions?

Pretty much, yes. You can safely assume that the 20050101 way of storing AVC in Matroska will not be the final way, and that it won't be playable in the mid to far future.

kurt
1st February 2005, 14:28
with todays ffdshow build playback of avc in mkv (and haali-splitter) is fine now :)

http://www.aziendeassociate.it/cd.asp?dir=/ffdshow

Mosu
1st February 2005, 15:12
Originally posted by kurt
with todays ffdshow build playback of avc in mkv (and haali-splitter) is fine now :)

Really!? That's great! Just to make sure: playback of AVC in Matroska created with mkvtoolnix >= 20050125 works with that version?

Mosu

kurt
1st February 2005, 15:32
jep, but i used mkvtoolnix from 30.1.05 and it plays well with AVC in it!!

Shinobu
1st February 2005, 17:18
the mkv i muxer with 01/01/2005 version of mmg are ok too ^^
cooooool ! thanks for your works

++

Mosu
1st February 2005, 17:44
Originally posted by Shinobu
the mkv i muxer with 01/01/2005 version of mmg are ok too ^^

Don't keep those around, though. Like I said, that's not the official way to store AVC.

JasonFly
1st February 2005, 20:58
Yes, the 01/02/2005 ffdshow solve this choppy playback problem for me.
Mosu, thank you for this beautiful "Cornflake girl" build of mkvtoolnix.

Mosu
6th February 2005, 22:04
Hey,

I have a new release of mkvtoolnix -- 1.0.2. This is not the long-awaited release with the tons of new features like support for AVC, MPEG-1/-2 etc. Neither does it contain all the bug fixes that the current development version contains. It is merely a release that works with today's releases of libebml and libmatroska. Nevertheless a few bug fixes are present as well.

For those who want to build it (like the packages): please be aware that you need libebml 0.7.3 and libmatroska 0.7.5 which were released not an hour ago. You can grab their sources at http://dl.matroska.org/downloads/

The usual links to...
...the homepage:
http://www.bunkus.org/videotools/mkvtoolnix/
...the sources:
http://www.bunkus.org/videotools/mkvtoolnix/sources/mkvtoolnix-1.0.2.tar.bz2
...the Windows installer:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-1.0.2-setup.exe

Binary packages for other systems/distributions are available from the home page.

Here's the ChangeLog since 1.0.1:
----------------------------------------------------------
2005-02-06 Moritz Bunkus <moritz@bunkus.org>
* Released v1.0.2.
* all: bug fix: Fixed compilation with the upcoming new versions of libebml and libmatroska.

2005-01-22 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: mkvmerge did not accept XML chapter files created with older mkvtoolnix versions due to deprecated chapter elements. Such elements are now skipped.

2004-12-18 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: Again the window handling. Hopefully this is better than the other attempts.

2004-12-15 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: One was able to crash mmg by pressing 'ok' in the muxing dialog right after muxing finished, especially if the 'abort' button was hit before. This mostly happened on Linux.
* mkvmerge: bug fix: Fixed negative audio displacement for a couple of formats.
----------------------------------------------------------

Have fun :)

Yong
7th February 2005, 11:58
Many thanks, Mosu:)

ermannob
8th February 2005, 23:11
:thanks:

bond
10th February 2005, 12:44
Originally posted by Mosu
If you all want a technical explanation of what's going on:

MP4 files can contain an atom named CTTS. Especially for AVC/h.264 video tracks. This atom maps the timecodes usually found in a MP4 file to display timecodes. Normally, the timecodes are 0ms, 40ms, 80ms, 120ms... etc. for a 25 FPS file. With a CTTS atom these can become e.g. 0ms, 120ms, 40ms, 80ms... This is also the case for B frames in "normal" MPEG-4.
...
Therefore the Matroska team (more like Haali and me) decided to do it the "right" way and to store display timecodes. This is "right" because Matroska does indeed store display timecodes. This is also true for what I call "native MPEG-4 storage" or "native B frames"beaware that ctts is also needed without b-frames, when the encoder does some frame reordering (eg p-frames), which is possible in avc and already done in mainconcept (have a look here (http://forum.doom9.org/showthread.php?s=&threadid=80952&perpage=20&pagenumber=2)) via the "reordering delay" option (isnt enabled if b-vops are enabled no matter what is set in the gui)

Mosu
10th February 2005, 12:49
Originally posted by bond
beaware that ctts is also needed without b-frames, when the encoder does some frame reordering (eg p-frames), which is possible in avc and already done in mainconcept

I know, and mkvmerge will always print the following warning if no CTTS atom is found:

The AVC video track is missing the 'CTTS' atom for frame timecode offsets. However, AVC/h.264 allows frames to have more than the traditional one (for P frames) or two (for B frames) references to other frames. The timecodes for such frames will be out-of-order, and the 'CTTS' atom is needed for getting the timecodes right. As it is missing the timecodes for this track might be wrong. You should watch the resulting file and make sure that it looks like you expected it to.

Unfortunately I have two MP4 files without CTTS atoms that are perfectly fine. In such cases this warning will be a "false positive".

bond
10th February 2005, 12:56
Originally posted by Mosu
Unfortunately I have two MP4 files without CTTS atoms that are perfectly fine. In such cases this warning will be a "false positive"with avc? propably muxed with an old version of mp4creator (it should set the ctts right now for avc with b-frames)

note that mp4creator (and therefore mp4ui too) with asp will not set a ctts when you mux from .avi to .mp4 (what most people will do), if you mux from raw to .mp4 they do it

yeah, thats mpeg4ip... :rolleyes:

Mosu
10th February 2005, 13:00
Originally posted by bond
with avc? propably muxed with an old version of mp4creator

Dunno. Someone provided those samples, I just downloaded them ;) But playback is fine for those. At least on Linux with mplayer and ffmpeg. But I guess that ffmpeg is not as bitchy about the timecodes on Linux as Nero's decoder is, so those files might not play on Windows. Anyway, having the warning is a good thing, especially in light of...

note that mp4creator (and therefore mp4ui too) with asp will not set a ctts when you mux from .avi to .mp4 (what most people will do), if you mux from raw to .mp4 they do it

:( mkvmerge will have the same problem. Muxing from AVI will be a bitch. I'll have to parse the bitstream in order to find out frame types/references. That's so much work...

bond
10th February 2005, 13:12
Originally posted by Mosu
Dunno. Someone provided those samples, I just downloaded them ;)lol, well if you run mp4info from mpeg4ip you will see the used streams (or open it in mp4ui, if they say "invalid" as description, its avc :D )
but beaware to only open a copy of your files in mp4ui, as mp4ui has the "nice" feature to optimize (aka rewrite) the files whenever you open them automatically, i dont trust it

But playback is fine for those. At least on Linux with mplayer and ffmpeg. But I guess that ffmpeg is not as bitchy about the timecodes on Linux as Nero's decoder is, so those files might not play on Windows.yep might be, still what counts are the avc specs, not what players do, cause i think that the players surely do some assumptions about what the ctts says and so ignore it, a method that might not work on all streams :(

mkvmerge will have the same problem. Muxing from AVI will be a bitch. I'll have to parse the bitstream in order to find out frame types/references. That's so much work...:(

filewalker
12th February 2005, 21:16
A little cosmetic bug...

During muxing the progress bar doesn't show the "green bar" anymore(mkvmerge GUI v.1.0.2).

Cu filewalker

Dick Buttkiss
14th February 2005, 01:59
I'm using mkvtoolnix 1.0.2 and I'm having a problem with chapters not showing up at all.


I load a chapter file in a *.txt format. mkvtoolnix opens and parses the chapters correctly, but when I mux everything together mediaplayer classic 6.4.8.2 (latest ver) doesn't see any chapters in my *.mkv file.

When I mux chapters in VDub-mod everything works fine. However, I like your chapter editor more. I didn't seem to see anything in the last few pages that helped me.

thana
14th February 2005, 02:12
the chaptereditor in mmg has nothing to do with the other settings for muxing. you have to save the chapters to a file first and then add them in the 'global'-tab as 'chapter file' and then mux normally. or you can first mux your file without chapters, and then add the chapters in the chaptereditor with "save to matroska file".

Dick Buttkiss
14th February 2005, 02:35
Originally posted by thana
the chaptereditor in mmg has nothing to do with the other settings for muxing. you have to save the chapters to a file first and then add them in the 'global'-tab as 'chapter file' and then mux normally. or you can first mux your file without chapters, and then add the chapters in the chaptereditor with "save to matroska file".

That was it, thanks man.

Dreassica
15th February 2005, 00:53
Stumbled across a weird problem with ssa subtitles muxed in with mkvtoolnix 1.0.2 Whenever a line ends with a comma it wont show up at playback when muxed in via MKVtoolnix. They do show when I play them back via softsub thoough. Maybe a small bug?

rawr
15th February 2005, 11:36
Bump for the speex support request a while back. Though you're obviously busy with other bits at the moment, I have a definate usage for this atm (director's comments track... not worth bloating a file over, but reasonable quality very low bitrate would make it worth backing up), and can see other usage (audio books -> mka etc).

rawr.

Mosu
17th February 2005, 23:07
Originally posted by Dreassica
Stumbled across a weird problem with ssa subtitles muxed in with mkvtoolnix 1.0.2 Whenever a line ends with a comma it wont show up at playback when muxed in via MKVtoolnix. They do show when I play them back via softsub thoough. Maybe a small bug?

Probably. I haven't forgotten about this, but I haven't looked at it yet either. It should be easy enough to fix. I'll get to it this weekend.

Mosu
17th February 2005, 23:13
Originally posted by rawr
Bump for the speex support request a while back.

Ok, I've talked a bit to a guy on IRC (illi) about Speex. I think I can get it working although there are no specs for Speex :( (at least not about what I need to know -- the bitstream format. There are specs about the algorithms/methods used, but those don't help me ;)) But I won't work on it before the next release (due hopefully end of next week).

Mosu
17th February 2005, 23:15
Originally posted by thana
the chaptereditor in mmg has nothing to do with the other settings for muxing. you have to save the chapters to a file first and then add them in the 'global'-tab as 'chapter file' and then mux normally.

Very true, and often a source for confusion. I think I'll have to add a warning if there are chapters loaded when muxing is about to start although no chapter file has been selected on the "global" tab (and only then. No need for too many warnings). The chapter editor should have been in its own dialog and not yet another tab, but it's always easy to say that with hindsight.

Mosu
19th February 2005, 15:37
Originally posted by Dreassica
Stumbled across a weird problem with ssa subtitles muxed in with mkvtoolnix 1.0.2 Whenever a line ends with a comma it wont show up at playback when muxed in via MKVtoolnix. They do show when I play them back via softsub thoough. Maybe a small bug?

I've tested mkvtoolnix 1.0.2 and current SVN, and neither one drops such a comma. Please have a look at your file in a hex editor (or use mkvextract to extract that SSA track again and look at the resulting file) and make sure that the comma is really not present in the file. If it is then it's a problem with some part of the playback software (VSfilter?).

karl_lillevold
21st February 2005, 01:02
I just tried the latest Guliverkli Matroska Splitter and discovered a little problem playing back my trans-muxed RealVideo files. They all have the framerate set to 30.00 fps (RM is inherently VFR, and this might be the max FPS as read by mkvmerge in the RM header I presume).

However, the actual framerate is 23.976. With the previous version of Matroska Splitter, reclock does not detect the framerate and I can manually set it to 23.976. The "problem" with the newer splitter is that now Reclock gets 30.00 as the framerate, and it is not possible to change it back to 23.976 fps. The only solution I have found is to go back to the older splitter version.

Could it perhaps be possible to allow changing the framerate in the MKV file with something like Matroska Properties, in the same way it can now change the display size...? Is it possible to "brute force" hex edit the MKV files?

Alternatively, there does not seem to be an option in mkvmerge to set the framerate, if I were to re-mux all the files and set the framerate correctly..

b166er
23rd February 2005, 19:49
MKV being VFR I doubt it would work. Maybe the pb is in MatroskaSplitter ? Have you tried Haali's splitter ?

karl_lillevold
23rd February 2005, 20:52
I know Matroska is VFR, just like RM, but there seems to be a default time for each frame. From mkvinfo:
+ Writing application: mkvmerge v0.8.8
+ Default duration: 33.333ms (30.000 fps for a video track)
Even though this is a 23.976 fps clip.

On another video it's OK though:
+ Writing application: mkvmerge v1.0.1 ('October Road')
+ Default duration: 41.708ms (23.976 fps for a video track)
where I seem to have used a newer mkvmerge. So I tried to re-mkvmerge one of the problem files, with the very latest mkvmerge, but this did not make any difference. I am not sure if mkvmerge version makes a difference though. Whether files end up as 23.976 or 30.000 seem relatively random, even with the same mkvmerge version (0.9.6).

I wish there was a way to correct the files with problems.

Haali's Matroska Splitter does not work well for me at all, and crashes both MPC and Zoomplayer with many of my Matroska files. However, it does play one of the problem files, and it results in the same reclock problem.

Prettz
23rd February 2005, 21:58
Originally posted by karl_lillevold

Alternatively, there does not seem to be an option in mkvmerge to set the framerate, if I were to re-mux all the files and set the framerate correctly..
Actually, I could probably make use of a feature like that too, especially if I'm eventually forced to stop using VDM. An option like VD and VDM have, where you can either manually enter the video framerate or set framerate to match the audio duration, would be nice.

b166er
24th February 2005, 11:36
Originally posted by karl_lillevold
I know Matroska is VFR, just like RM, but there seems to be a default time for each frame. From mkvinfo:
+ Writing application: mkvmerge v0.8.8
+ Default duration: 33.333ms (30.000 fps for a video track)
Even though this is a 23.976 fps clip.

On another video it's OK though:
+ Writing application: mkvmerge v1.0.1 ('October Road')
+ Default duration: 41.708ms (23.976 fps for a video track)
where I seem to have used a newer mkvmerge. So I tried to re-mkvmerge one of the problem files, with the very latest mkvmerge, but this did not make any difference. I am not sure if mkvmerge version makes a difference though. Whether files end up as 23.976 or 30.000 seem relatively random, even with the same mkvmerge version (0.9.6).

I wish there was a way to correct the files with problems.

I assume when remuxing mkvmerge is using the default duration from the mkv file... So remuxing shouldn't fix that. Maybe you could try to save it to AVI or rm and then back to matroska ? Of course there is still the hex editor hack...

Mosu
24th February 2005, 12:00
(RM is inherently VFR, and this might be the max FPS as read by mkvmerge in the RM header I presume).

.rm --> .mkv: The Real Media File Format contains a header field called 'fps'. mkvmerge uses its contents for the 'default duration' element and as the duration for each video frame. Are you saying that this header field contains the maximum FPS encountered in the whole file? That would practically make it worthless IMHO.

.mkv --> .mkv: mkvmerge uses the 'default duration' element if one was present. If not, the output file will not have a 'default duration' for that track. The duration of each frame is copied 1:1 into the output file.

So. If a MKV says that it's 30fps then that's because the original .rm said it's 30fps as well. Adding a parameter for setting the default duration ( = 1/fps) could solve your problem partially, but how should it set the duration of each frame? In the .rm --> .mkv case this is easy -- the duration of each frame is 1/(forced new FPS). But for .mkv --> .mkv I can't simply do that (well I can, but the user can easily shoot himself in the foot with that).

karl_lillevold
24th February 2005, 19:20
Mosu: thanks for clarifying.

Originally posted by Mosu
.rm --> .mkv: The Real Media File Format contains a header field called 'fps'. mkvmerge uses its contents for the 'default duration' element and as the duration for each video frame. Are you saying that this header field contains the maximum FPS encountered in the whole file? That would practically make it worthless IMHO.
It's even worse :( It contains the MaxFrameRate parameter used for Producer, which has no relation to the actual framerate in the RM file, except if producer encounters a /higher/ framerate, it will skip frames. Tools like AutoRV10 just sets MaxFrameRate to 30, even though the actual /fixed/ framerate of the video is 23.976, 25.00 fps, or 29.97 fps. All my audience templates likewise, since (until now) there really was no reason to modify this. In fact, to avoid users shooting themselves in the foot, by setting MaxFrameRate to a lower number than the actual framerate, thus causing Producer to skip frames, I have suggested always using 30 fps. One common mistake seen was settting MaxFrameRate to 24, input sequence is 29.97, frames are skipped and Producer's inverse telecine would fail.

What I have not yet figured out is how some of the MKV files came out correctly... :confused: I would have thought every sample I have has MaxFrameRate set to 30. Unfortunately I no longer have the RMVB original for those MKVs that are correct, but I will keep it in mind and check when I happen to transmux next time..

I am sure if they had re-designed RMFF today, it would have been different.. Right now it is quite useless, as you say, and a 'default duration' like Matroska has, would have been better.

.mkv --> .mkv: mkvmerge uses the 'default duration' element if one was present. If not, the output file will not have a 'default duration' for that track. The duration of each frame is copied 1:1 into the output file.
This sounds like the only possible solution.

So. If a MKV says that it's 30fps then that's because the original .rm said it's 30fps as well. Adding a parameter for setting the default duration ( = 1/fps) could solve your problem partially, but how should it set the duration of each frame? In the .rm --> .mkv case this is easy -- the duration of each frame is 1/(forced new FPS). But for .mkv --> .mkv I can't simply do that (well I can, but the user can easily shoot himself in the foot with that).
I am not sure what would work best, but right now there is a slight mismatch in the RMFF -> MKV process in that one parameter is translated into a different one. In most cases it does not matter. Only when a filter (like Reclock) tries to find the framerate, and Matroska Splitter provides this wrong number, there is a problem.

I will suggest to D-C that AutoRV10 uses the actual source fixed framerate as the MaxFrameRate. This could solve the problem for one specific usage scenario, but is not very general.

Mosu
24th February 2005, 20:54
Thanks for the explanation, Karl. Looks like I'll have to change mkvmerge to ignore the FPS header field completely. I'll also add a --default-duration parameter (or sth similar) that will override whatever mkvmerge usually thinks is the default duration. I don't think I'll add that to the GUI, though. It contains too many options already :/ Maybe it's time to introduce a separate dialog for seldom-used track specific options (e.g. the "fourcc" field could safely be moved there as some others. This might even free up some space that I could give to the two list boxes -- they're pretty small at the moment).

Mosu
24th February 2005, 21:33
Haali just reminded me that I've already added such an option in the development version available at http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/HEAD/ :

--default-duration <TID:Xms|us|ns> Force the default duration of a track to X.

Maybe you could give it a try.

Bluedan
24th February 2005, 23:20
Mosu, what's the current state of the head section aka pre1.2.0?

Once in the past I knew where to look for a change log. :rolleyes:
How far are you away from <higher aims> (i.e.DVD menue transitions??).
Is AVC implementation considered as _quite_ ready?

The last news (http://www.bunkus.org/videotools/mkvtoolnix/avc-status.html) written here are nearly 2 weeks old and there has been a new build nearly every day....

karl_lillevold
25th February 2005, 01:43
Originally posted by Mosu
Maybe you could give it a try.
I did and it works -- Thanks! After using mmg to construct command line and then adding --default-duration 0:41708us in front of the RMVB filename argument, I ended up with (almost) 23.976 fps as default framerate. I remuxed with 41708375ns and got exactly 23.976 ;) Hope you can find a way to add it to the GUI.

pest
25th February 2005, 03:02
Hi Mosu,
first let me thank you for mkvtoolnix...it's quite stable
since the first days of my use

but i wonder if it's possible to mux rared idx/subs?
mmg is crashing if i try 1.0.1 or mkvhead-05.02.20

would be nice, because the subs compress about 1:7