Log in

View Full Version : MKVToolNix v24.0.0 released


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 [13] 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105

Mosu
28th December 2010, 14:01
but either way is there any way to mux the AC3 into an MKV without it skipping parts of the stream?

Not with mkvmerge, no. In Matroska such garbage data would be invalid anyway.

Even though there's no doubt non-audio sections in the edited AC3 stream for some reason (I don't know what VirtualDubMod is doing there) it remuxes the video into an AVI which stays in sync and which plays perfectly, so I'm wondering if MKVMergeGUI can do the same thing.

mkvmerge usually does a good job at staying in sync if the garbarge is at the very beginning by calculating the delay that garbarge inside the AVI represents. If there's garbarge somewhere in the middle then you're mostly out of luck.

yetanotherid
29th December 2010, 18:45
mkvmerge usually does a good job at staying in sync if the garbarge is at the very beginning by calculating the delay that garbarge inside the AVI represents. If there's garbarge somewhere in the middle then you're mostly out of luck.

Thanks for the reply.
But yeah..... it's the garbage in the middle which causes the problem. No doubt I can get around it. Re-encoding the audio stream while it's still inside the originally edited file seems to do the job (via directshow) but I thought I'd ask in case there is a way to avoid re-encoding which I'd been missing.

Cheers.

yetanotherid
31st December 2010, 03:05
I just thought I'd add something to my previous post in case someone with a similar problem stumbles across it. So far, I've been able to split files containing AC3 audio using VirtualDub 1.9.10 without any sync issues while remuxing to MKV, while the last version of VirtualDubMod does something to cause the sync problem when it edits.
For VirtualDub you need to install the AC3 plugin or it'll not not what you're giving it when the audio is AC3, and it'll laugh at you when you try to import AC3 audio without the plugin.

Episodio1
31st December 2010, 03:39
YETANOTHERID, yes, I have same problems with VDubMod: after you demux AC3 you have to run "ac3fix.exe" to fix that AC3 file. The output file will be OK for Mkv always.

yetanotherid
1st January 2011, 06:13
YETANOTHERID, yes, I have same problems with VDubMod: after you demux AC3 you have to run "ac3fix.exe" to fix that AC3 file. The output file will be OK for Mkv always.

Thanks for that. There's a program/utility for everything. :)
I also read where someone suggested demuxing with Project X would fix the problem too, although I can't remember where.

Unfortunately though I had a dummy spit and deleted all the files and started again, so now all the editing has been done with VirtualDub so I've not got any out of sync audio to test. I'll have to make one later and try them both out.

It seems kind of odd VirtualDubMod seems to make a mess of the AC3 as it edits video, while VirtualDub does not... Given the first supports AC3 audio but the second requires a third party plugin to open/decode it. At least it seems somewhat odd to me.

dirk362
1st January 2011, 13:33
Feature Request - Artist property via mkvpropedit
To be able to set the Artist property field via scripts etc.

At present properties such as Title is setable, but some applications also set Artist as part of their encoding to match their application name.
I'm all for shameless plugs of the programmers efforts, but feel it more preferable to have Artist relate to the original creator of the works.

Mosu
1st January 2011, 13:46
Matroska file headres don't contain a field for an author. What you want would require tags, and mkvpropedit cannot edit/replace set tags at the moment. This is planned, but without any priority.

Xanderian
7th January 2011, 11:40
hello mosu,
mkvmerge 4.4 here

trying to mux a mov into mkv but for the audio track i get this error

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

so the file output has no audio..do you have any suggestions ? I can pm you a link for the file btw..

Mosu
8th January 2011, 19:48
You can upload it, but I cannot promise you when or even if I take a look at it. The QuickTime format is not really a priority for me at the moment.

MrVideo
8th January 2011, 21:49
Tools 4.4.0

I have some h.264 source files, both 1080i and 720p.

When I use the --default-duration 0:59.94fps on 720p source, the playback is at 59.94 fps.

But, for the 1080i h.264 source (from two different suppliers), the 0:29.97fps setting appears to used, as mediainfo shows the frame rate as being 29.97. But, when VLC plays it back, or when streamed to my Blu-ray player, the audio is at the right speed, but the video appears to be at 25 fps.

[... time delay while I try something ...]

Actually it is 15000/1001 fps. As a wild stab, I set the frame rate to 59.94, which is totally wrong for interlace 1080 video, but now it plays correctly.

Anyone have any ideas why double the frame rate needs to be set for it to work?

Mosu
9th January 2011, 18:37
mkvmerge has a known issue with calculating the default FPS for interlaced h264 video. I cannot give you a time frame when or if I might get around to working on it.

I'd be really grateful if someone with knowledge about interlaced h264 could chime in a give me some clues about how to derive a frame's duration in interlaced cases. Does the frame rate in the h264 headers (the SPS or whereever it is stored) simply apply to fields in those cases? I'd guess "not always".

MrVideo
9th January 2011, 19:11
mkvmerge has a known issue with calculating the default FPS for interlaced h264 video. I cannot give you a time frame when or if I might get around to working on it.

OK, no rush, as there is a workaround.

madshi
9th January 2011, 19:27
I'd be really grateful if someone with knowledge about interlaced h264 could chime in a give me some clues about how to derive a frame's duration in interlaced cases. Does the frame rate in the h264 headers (the SPS or whereever it is stored) simply apply to fields in those cases? I'd guess "not always".
IIRC, the h264 "frame rate" is actually always the *field* rate. So e.g. for 1080i50 content, you have a field rate of 50. For 1080p50, you have a field rate of 100. For 1080p24 you have a field rate of 48/1.001. For 1080i60 you have a field rate of 60/1.001.

The average duration of an interlaced field should be "1000 / field rate" milliseconds. The average duration of a progressive frame should be "1000 / frame rate" = "2 * 1000 / field rate".

The QuickTime format is not really a priority for me at the moment.
What is a priority for you at the moment? Or is it a secret? :)

Mosu
9th January 2011, 19:36
Thanks for the info, Madshi. With that info fixing it shouldn't be too hard.

My priorities are pretty much fixing bugs and improving the documentation. Yeah, that's not a lot. Programming in my free time is on the back burner for me for the time being. Mostly a motivational issue as I program full time for a living at the moment. And no matter how much I like programming it's mentally exhausting.

With that being said I think I'll take a look at the frame/field rate issue sometime next week.

Xanderian
10th January 2011, 10:27
Mosu I've uploaded the mov file starting with Exp* along with the caps..Hope you can take a look at this issue..

shon3i
22nd January 2011, 12:54
I have somehow weird problem, i don't know that maybe hardware fault, or is just problem with mkvtoolnix, other muxers are not show this behavior.

I have perfectly "gitch" free 264 stream, when i muxed and watch or examine that stream with DGIndexNV, there is gitches.

Problem is that i can't replicate it every time, at same place. Sometimes muxing can pass without completly.

is there any tool can detect it or something?

btw i think i found way to check, stream will not demux here is eac3to log:

[a02] Invalid EBML data (1). <ERROR>
[a02] Invalid EBML data (1). <ERROR>
[v01] Invalid EBML data (1). <ERROR>
Aborted at file position 1929641984. <ERROR>

shon3i
22nd January 2011, 18:07
I think i found perfect way to check mkv for errors using mkvextract with

mkvextract tracks "input.mkv" which scans stream show errors (if any) without real extracting streams.

i will do future invastigate, and report what can be reason. And just less thinking that is problem is on hardware side, i already finished surface memory test without problems, now i do surface test for HDD's which i will have results later.

LeMoi
22nd January 2011, 18:08
Your file seems to be corrupted. Try mkvverify or even MPEG File Bitrate Viewer to check integrity

shon3i
22nd January 2011, 19:42
Thanks LeMoi, here is cutted log of scaned mkv.

(mkv parser) file is b0rked:
pos. 42,031,135: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,150: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,152: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,167: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,169: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,184: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,186: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,201: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,203: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,218: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,220: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,235: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,237: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,252: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,254: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,269: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,271: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,286: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,288: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,303: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,305: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,320: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,322: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,337: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,339: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,354: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,356: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,371: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,373: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,388: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,390: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,405: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,407: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,422: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,424: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,439: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,441: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,456: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,458: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,473: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,475: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,490: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,492: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,507: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,509: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,524: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,526: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,541: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,543: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,558: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,560: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,575: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,577: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,592: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,594: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,609: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,611: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,626: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,628: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,643: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,645: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,660: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,662: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,677: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,679: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,694: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,696: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,711: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,713: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,728: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,730: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,745: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,747: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,762: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,764: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,779: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,781: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,796: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,798: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,813: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,815: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,830: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,832: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,847: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,849: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,864: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,866: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,881: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,883: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,898: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,900: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,915: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,917: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,932: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,934: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,949: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,951: 1st byte of EBML-ID indicates size larger than 4

(mkv parser) warning:
pos. 42,031,966: element size of 0 encountered

(mkv parser) file is b0rked:
pos. 42,031,968: 1st byte of EBML-ID indicates size larger than 4

Cheshire Cat
23rd January 2011, 06:58
No idea, sorry.

Don't know if you recall my posts, but they are right at the last page.

Since our last talk i have been kind of "debugging" what could cause those access issue to mkvs made with more recent mkvtoolnix versions and i've gathered some new data...

In the meanwhile i've tested mkvtoolnix on windows xp. Last version - 4.4.0 - and haven't had any problems. Haven't tested on vista though. But since 7 is my main OS, i guess that is what matters.

With Google's help i've been able to track down some other people with similar complaint and with some testing i've able been able to pinpoint the issue to be somewhat related to the file being left indefinitely open after being accessed (maybe somewhat related to thumbnailing since the files who show these symptoms never show any kind of thumbnail). Let me remind that they are somewhat blocked. Readable but unable to be deleted, renamed or moved. Just after a reboot and even then sometimes they refuse to budge. If one disables the "details pane" the files are indeed movable/deletable & etc. But as soon as that pane is turned back on, problems return with the "defective" files.

I've also been trying different mkvtoolnix versions since the older ones and currently i'm at 3.2.0.0. At the moment things still do work perfectly and i can't report any problem. But as you can imagine testing one version at a time is indeed time consuming. So in a shortcut fashion, could you, or would you be able to say if at a given time you have introduced some modifications to the way mkvtoolnix handles remuxed files?

Since the program's older versions don't have any problems and this symptoms i have been report only show up at these newer versions it has to be some bug related with mkvtoolnix, the way it handles/writes files and/or/with windows 7 explorer...

sneaker_ger
23rd January 2011, 07:55
Just to be sure: did you really deactivate header removal compression? I'm asking because the mkvinfo log from your 4.4.0 file shows that it is in fact activated for that file, not deactivated.

Since no version of Windows comes with any kind of Matroska splitter the problem may indeed lie with DivX/Haali or whatever splitter the explorer is using. (Though I think that newer Haali versions do not include shell extensions anymore due to severe problems with them.)

Mosu
23rd January 2011, 11:34
So in a shortcut fashion, could you, or would you be able to say if at a given time you have introduced some modifications to the way mkvtoolnix handles remuxed files?

The one important thing that has changed in header removal compression: http://www.bunkus.org/videotools/mkvtoolnix/faq.html#header_removal_compression

There are no changes in the way or when mkvmerge/mmg open/close files when adding/muxing them.

Cheshire Cat
23rd January 2011, 16:48
Just to be sure: did you really deactivate header removal compression? I'm asking because the mkvinfo log from your 4.4.0 file shows that it is in fact activated for that file, not deactivated.

Since no version of Windows comes with any kind of Matroska splitter the problem may indeed lie with DivX/Haali or whatever splitter the explorer is using. (Though I think that newer Haali versions do not include shell extensions anymore due to severe problems with them.)

Yes i already tried, as Mosul suggested, to disable the HRC unfortunately with no effect. I must say on Windows 7 since on XP i had no need. mkvtoolnix 4.4.0 worked just fine. Both systems are running pretty much the same applications (as i've though about some conflict) and both systems are running the same codec combinations.

Cheshire Cat
23rd January 2011, 16:57
The one important thing that has changed in header removal compression: http://www.bunkus.org/videotools/mkvtoolnix/faq.html#header_removal_compression

There are no changes in the way or when mkvmerge/mmg open/close files when adding/muxing them.

Thanks for you patience! I guess i will keep trying different versions until i stumble upon one which replicates these issues in order discover what may be causing this.

nlnl
23rd January 2011, 20:49
Mosu
Will you include this fix for Haali + DTS HD MA mkvtoolnix-unicode-4.4.0-build20101115-315-setup (http://www.bunkus.org/videotools/mkv...-315-setup.exe) in future 'official' 4.0.1 release?
The fix sets the "default duration" header value for DTS audio tracks of any kind.
Thanks!

Mosu
23rd January 2011, 21:13
Anything in a pre-build will also be in the next release.

Cheshire Cat
24th January 2011, 07:23
Hi once more. Got news this time!

After a marathon trying different versions of mkvtoolnix indeed did find some new info.

The major culprit is the thumbnail component from Divx. After testing all the versions, and with the help of Google i stumbled upon a thread describing the exact same symptoms.

What was leaving me even more puzzled on this was that the problems don't start up immediately at version 4.1.0.0 - that was when hrc was added to mkvtoolnix, ain't i correct?

In fact i can use 4.1.0.0 and 4.1.1.0 just fine. Only from 4.2.0.0 ahead i have the issues described.

So, i gave it a try, un-installed Divx and re-tested the versions. There wasn't a single problem.

So what may be causing this so that it works just with some mkvtoolnix version? Incompatibilities? Any ideas?

sneaker_ger
24th January 2011, 08:33
So you're basically saying it was what we were telling you the whole time and that you made some mistakes in your tests?

4.2.0 is the first version in which header removal compression is on by default for h.264 video tracks.

Mosu
24th January 2011, 09:07
The DivX thumbnail component is even mentioned explicitely in my FAQ entry (http://www.bunkus.org/videotools/mkvtoolnix/faq.html#header_removal_compression).

Cheshire Cat
24th January 2011, 23:54
The DivX thumbnail component is even mentioned explicitely in my FAQ entry (http://www.bunkus.org/videotools/mkvtoolnix/faq.html#header_removal_compression).

Since you are the most probable "faq" creator i do not need to paste it here. The faq mentions explorer crashes. I never had explorer crashes. Only the already reported sluggishness trying to deal with mkv files. As you may see what was happening to me did not fit completely the descriptions related to the divx component as you wrote about them on the faq.

Cheshire Cat
24th January 2011, 23:58
So you're basically saying it was what we were telling you the whole time and that you made some mistakes in your tests?

4.2.0 is the first version in which header removal compression is on by default for h.264 video tracks.

If you manage to re-read my posts, and as i've replied to Mosul, you will be able to see that the issues i were experiencing don't fit exactly the descriptions of solely HRC or the thumbnails issue. At a stretch you could say that somehow they are related.

Having the faq as source and on relation to the divx problem - i never had any kind of explorer crashes.

Also having been said from you guys, and taken from the faq also, disabling only the HRC wasn't a solution also.

I had to uninstall the divx thumbnail component and as far as i recall none of you guys has mentioned that detail nor it is mentioned as a possible solution on the faq.

Sorry for the double post, my bad.

LeMoi
25th January 2011, 00:06
I installed too this DivX component on my laptop, but not on my main PC. This component is just buggy and outdated, reported informations are often wrong (especially duration), and thumbnail extraction worked about 2 days, and since then, doesn't work anymore. I just kept it because Explorer can now read some media informations such as resolution of MKV files, but i don't recommend anyone to install it!

SamuriHL
25th January 2011, 00:08
Use MediaInfo for such information. The DivX plugin has been a known problem for years now. One would have thought they'd fix it by now but that is a pipe dream.

sneaker_ger
25th January 2011, 00:34
If you manage to re-read my posts, and as i've replied to Mosul, you will be able to see that the issues i were experiencing don't fit exactly the descriptions of solely HRC or the thumbnails issue. At a stretch you could say that somehow they are related.

Having the faq as source and on relation to the divx problem - i never had any kind of explorer crashes.

Also having been said from you guys, and taken from the faq also, disabling only the HRC wasn't a solution also.

I had to uninstall the divx thumbnail component and as far as i recall none of you guys has mentioned that detail nor it is mentioned as a possible solution on the faq.

Sorry for the double post, my bad.

We both mentioned DivX, but fair enough, you did not experience explorer crashes.

I can't help but to still think that your problem is related to header removal compression, since your problems starts with version 4.2.0. I know you said you deactivated it. Did you make sure that you didn't have any files with HRC in the same folder (or desktop) when you were testing it? Did you look into the mkvinfo log to make sure it really was deactivated? I can't see anything else in the changelog for 4.1.1 -> 4.2.0 that looks suspicious.

It may be better to take this to the guys at DivX, though I think they probably know about the issues already. Even if there was a problem with the files created with 4.2.0 and later (I doubt it, but there is no way to be sure of course), the DivX software is buggy.

Cheshire Cat
25th January 2011, 00:36
How to uninstall without removing Divx? I tried an application found at Divx forums to tweak the codec properties and it had the option to remove the thumbnail component, but unfortunately it did nothing, things kept just like if i had used it. And Divx not being absolutely needed it quite handy.

I did not knew that the video only started being compressed at 4.2.0.0 as the fact said that since 4.1.0.0 HRC was included i assume it was already integrated and working, so i did not understand why it was doing that just from 4.2.0.0 and after.

And i did not have explorer crashes nor disabling/enabling the hrc solved anything. Just removing Divx and therefore that thumnail component.

LeMoi
25th January 2011, 00:38
Maybe you can uninstall it and reinstall without this component?

Cheshire Cat
25th January 2011, 00:46
We both mentioned DivX, but fair enough, you did not experience explorer crashes.

I can't help but to still think that your problem is related to header removal compression, since your problems starts with version 4.2.0. I know you said you deactivated it. Did you make sure that you didn't have any files with HRC in the same folder (or desktop) when you were testing it? Did you look into the mkvinfo log to make sure it really was deactivated? I can't see anything else in the changelog for 4.1.1 -> 4.2.0 that looks suspicious.

It may be better to take this to the guys at DivX, though I think they probably know about the issues already. Even if there was a problem with the files created with 4.2.0 and later (I doubt it, but there is no way to be sure of course), the DivX software is buggy.

I find it really weird to be only related to hrc. No other people complaint about mkvtoolnix + hrc when normally using Windows. Why would my PC do it? As you have said that it is inly enable for video from 4.2.0.0 does make a sense now because both older version 4.0 an 4.1 don't have problems.

Disabling hrc on 4.2/3 & 4 does no good. But as soon as i uninstall Divx things work just fine.

I have a 30GB partition dedicated precisely to this kind of work/tests. I've tried with one file at a time, since when they had those problems it was extremely hard to rename/move or even delete. The last thing i wanted was to have a couple of files, several GB large, residing on my drive because they would be a pain to remove.

I'm not bashing Divx but since it is explained why problems only start at 4.2 it's pretty clear the problem is on their side and if here i reckon there is indeed support from authors i don't think that from Divx part things are similar. I may drop an e-mail but something tells they won't give it much attention. Don't really understand is why they bundle these thing on an installer without any option too chose what or what not to install.

Cheshire Cat
25th January 2011, 00:49
Maybe you can uninstall it and reinstall without this component?

There is no option for that.

You install the codec bundle + 3 other things - convert, web player and something else...

But i reckon it is not needed to be filling up mkvtoolnix thread with any more off-topic.

Let me just say thanks for your help guys! Even though it wasn't a mkvtoolnix problem you've been A+.

Betsy25
27th January 2011, 00:51
Could this framerate "bug" be related to many problems lately with audio/video sync issues appearing when streams were extracted from mkv and remuxed into .mp4 ?:stupid:

sneaker_ger
27th January 2011, 01:34
Are you talking about your problems with variable framerate? As Selur already told you, you have to copy the timecodes from your mkv file to your mp4 file. This is not a bug in mkvtoolnix. (I'm assuming here that you are in fact dealing with a vfr file - you haven't provided any timecodes, so I cannot check it.) Most GUIs out there don't take vfr into account and will fail miserably.
You can use this patched ffmpeg build (http://sourceforge.net/projects/direct264/files/Related%20Programs/ffmpeg%20(demuxer_muxer%20only)/) for simple remuxing purposes:
ffmpeg -i input.mkv -vcodec copy -acodec copy output.mp4

Betsy25
27th January 2011, 05:20
Are you talking about your problems with variable framerate? As Selur already told you, you have to copy the timecodes from your mkv file to your mp4 file. This is not a bug in mkvtoolnix. (I'm assuming here that you are in fact dealing with a vfr file - you haven't provided any timecodes, so I cannot check it.) Most GUIs out there don't take vfr into account and will fail miserably.
You can use this patched ffmpeg build (http://sourceforge.net/projects/direct264/files/Related%20Programs/ffmpeg%20(demuxer_muxer%20only)/) for simple remuxing purposes:
ffmpeg -i input.mkv -vcodec copy -acodec copy output.mp4

Thanks sneaker, yeah it was about the vfr issue, but when .mkv is opened in mkvtoolnix, i don't see any timecodes ?

sneaker_ger
27th January 2011, 06:22
It does not make sense for mkvmerge GUI to list timecodes, as every single Matroska track has them - they are always present. You can extract them using mkvextract, which is part of the mkvtoolnix package. You can use MKVcleaver (http://forum.doom9.org/showthread.php?t=152108) if you're not comfortable with using mkvextract from the command line. For usage with mp4 files see NHMLTransform (http://forum.doom9.org/showthread.php?t=150890).

Betsy25
27th January 2011, 21:58
Thank you very much sneaker, the patches ffmpeg build is working fine.:)

DragonQ
28th January 2011, 23:58
Sorry if this has been discussed before but with mkvmerge GUI 4.4.0, the MKV files I create aren't compatible with the latest version of tsMuxer and won't generate thumbnails within Windows 7 (which I think I managed to enable with CoreAVC - I don't think Haali Media Splitter worked).

If I use mkvmerge GUI 4.1.1, the files get thumbnails correctly and can be read by tsMuxer.

What changed between these two versions that could've caused this new incompatibility?

sneaker_ger
29th January 2011, 01:24
Header removal compression is used by default now for a variety of tracks. Go into options and tick "Disable header removal compression for audio and video tracks by default".
http://www.bunkus.org/videotools/mkvtoolnix/faq.html#header_removal_compression

DragonQ
29th January 2011, 02:20
Ah cool, that seems to work. Cheers.

Brazil2
6th February 2011, 16:57
I don't know why this thread hasn't been updated yet but MKVToolnix v4.5.0 has been released about one week ago:
http://www.bunkus.org/videotools/mkvtoolnix/

Changelog: http://www.bunkus.org/videotools/mkvtoolnix/doc/ChangeLog

SamuriHL
6th February 2011, 17:06
Probably cause the forum was down for almost a week. Thanks for posting that! Thanks, Mosu, for the new release!

Mosu
6th February 2011, 17:11
The downtime was indeed the reason. Here's the release message:

I've released mkvtoolnix v4.5.0. It contains a lot of bug fixes as well as a couple of new features and a few enhancements.

There are two important changes for package maintainers:

1. mmg's guide is now installed into the $docdir location ("--docdir" option to configure) instead of $datadir/mkvtoolnix. This usually means /usr/share/doc/mkvtoolnix/guide/... instead of /usr/share/mkvtoolnix/guide... As the guide was the only thing installed in $datadir/mkvtoolnix that directory is not needed anymore.

2. mkvtoolnix requires libebml 1.2.0 and libmatroska 1.1.0 for compilation. Both have been released a few days ago. However, starting with this release mkvtoolnix includes the source of libebml and libmatroska. configure will still try to find globally installed copies of libebml and libmatroska like before and use them if they're recent enough. If they're not then configure will fall back to using the included versions.

This breaks in certain cases. If CFLAGS/CXXFLAGS/LDFLAGS contain include/library path directives to directories containing older versions of libebml/libmatroska then configure will correctly say it'll use its internal copies of libebml/libmatroska but compilation will fail (due to the order in which CFLAGS/CXXFLAGS/LDFLAGS etc are passed to gcc). I plan to fix this for the next release. For the time being it should be enough NOT to specify include/library paths with any of these environment variables. Then you can even leave older copies installed and compilation will work.

Meaning:

Old libs in /usr/include/ebml /usr/include/matroska is OK.

Old libs in e.g. /opt/libebml /opt/libmatroska and configuring with CFLAGS="-I/opt/libebml -I/opt/libmatroska" LDFLAGS="..." ./configure will break.

Here are the usual links...

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

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

...to the Windows installer and 7zip archive:
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.5.0-setup.exe
http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.5.0.7z

All binaries that I provide myself have already been uploaded.

Here's the full ChangeLog since release 4.4.0:

------------------------------------------------------------
2011-01-31 Moritz Bunkus <moritz@bunkus.org>
* Released v4.5.0.
* build: Building mkvtoolnix now requires libebml v1.2.0 and libmatroska v1.1.0 or later.
* build: enhancement: mkvtoolnix now includes libebml and libmatroska. The configure script will use them if either no installed versions of them is found or if the installed version is too old.

2011-01-25 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Fixed an infinite loop when reading program stream maps in MPEG program streams. Part of a fix for bug 589.

2011-01-21 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: new feature: Added an option "--track-info" (short: "-t") that displays one-line statistics about each track at the end of the output. The statistics include the track's total size, duration, approximate bitrate and number of packets/frames.
* mkvinfo: bug fix: The hexdump mode was accessing invalid memory if the data to dump was shorter than 16 bytes. It was also outputting the values as characters instead of hexadecimal numbers. Patch by ykar@list.ru. Fix for bug 591.

2011-01-20 Moritz Bunkus <moritz@bunkus.org>
* mmg: enhancement: The output file name extension is automatically set to ".mk3d" if the stereo mode parameter for any video track is changed to anything else than "mono" or the default value.
* mmg: enhancement: Added ".mk3d" to the list of known file name extensions for Matroska files.
* mkvmerge, mmg: enhancement: Updated the "stereo mode" parameter to match the current Matroska specifications.

2010-12-26 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: enhancement: If mkvmerge encounters invalid UTF-8 strings in certain files or command line arguments then those strings will simply be cut short. Before mkvmerge was exiting with an error ("Invalid UTF-8 sequence encountered").
* all: new feature: Added online update checks. The command line tools know a new parameter "--check-for-updates". mmg has a new menu entry ("Help" -> "Check for updates") and checks automatically when it starts, but at most once in 24 hours. Can be turned off in the preferences. This function requires libcurl and is not built if libcurl is not available.

2010-12-22 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Avoid a crash due to invalid memory access if a source file name contains numbers (happens only if mkvtoolnix is built with MS Visual Studio). Fix for bug 585.

2010-12-21 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: Added support for reading VP8 video from Ogg files. Implements bug 584.
* mkvextract: enhancement: mkvextract will exit with an error if the user specifies track IDs that do not exist in the source file. This works in the "tracks" and "timecodes_v2" extraction modes. Fix for bug 583.
* docs: mkvextract's man page has been updated to match the program's expected command line syntax for the "timecodes_v2" mode. Fix for bug 583.

2010-12-20 Moritz Bunkus <moritz@bunkus.org>
* build system: Fixed building the Qt version of mkvinfo's GUI. Fix for bug 576.
* mkvmerge, mmg: bug fix: Option files could not contain options that started with '#' as they were interpreted as comment lines.

2010-11-15 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: The "default duration" header field is set for DTS audio tracks.

2010-11-09 Moritz Bunkus <moritz@bunkus.org>
* build system: mmg's guide and its images are installed into the location given by configure's "docdir" variable. Patch by Cristian Morales Vega (see AUTHORS).

2010-11-07 Moritz Bunkus <moritz@bunkus.org>
* all: Made the French translation selectable in all programs.

2010-11-01 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: On Mac OS X the application type is set to a foreground application preventing issues like the GUI never getting focus.
------------------------------------------------------------

Have fun.

LeMoi
8th February 2011, 14:20
Progress bar is not working anymore, instead of it I have this message :
The file 'xxx.mkv' has been opened for writing.
Progress: 0%
Progress: 10%
Progress: 20%
The cue entries (the index) are being written...
The file 'xxx.mkv' has been opened for writing.
Progress: 29%
Progress: 37%
Progress: 47%
Progress: 58%
Progress: 69%
Progress: 80%
Progress: 90%
Progress: 100%
The cue entries (the index) are being written...