MKVToolNix v24.0.0 released [Archive] - Page 7

vmrsss

9th August 2010, 16:12

Hi Mosu,

After the latest update, I can't build mkvtoolnix any longer. I am on macosx 10.6.4 snow leopard. This is where the compilation breaks down( almost immediately after start)

In file included from src/merge/cluster_helper.cpp:25:
src/merge/cluster_helper.h:17:31: error: calling fdopen: Bad file descriptor
In file included from src/merge/cluster_helper.h:25,
from src/merge/cluster_helper.cpp:25:
src/merge/pr_generic.h:18:31: error: calling fdopen: Bad file descriptor
In file included from src/merge/cluster_helper.cpp:27:
src/merge/output_control.h:18:31: error: calling fdopen: Bad file descriptor

Can you help?

Thx

Mosu

9th August 2010, 16:19

Not really. Try disabling the use of precompiled headers (though that's a feature that has been introduced prior to 4.2.0) with the configure option --disable-precompiled-headers

vmrsss

9th August 2010, 20:32

Not really. Try disabling the use of precompiled headers (though that's a feature that has been introduced prior to 4.2.0) with the configure option --disable-precompiled-headers

doesn't help, same error. this must be related to the introduction of "rake", which I had never seen before. The last version I built successfully is 4.1.1, which I believe is just the previous one, is it not?

mkvmerge --version
mkvmerge v4.1.1 ('Bouncin' Back') built on Jul 13 2010 03:40:35

Mosu

10th August 2010, 07:48

No, 4.2.0 does not use rake yet. Only the current development version in my Git repo does.

Just FYI: rake is a build tool written in Ruby with build description files (Rakefiles) also written in Ruby.

vmrsss

10th August 2010, 09:06

No, 4.2.0 does not use rake yet. Only the current development version in my Git repo does.

So, what am I doing wrong? When I ./configure after git pull and ./autogen.sh, I get no Makefile at all. So, make does not work. In fact, ./autogen.sh instructs me to run ./configure and then rake.

Mosu

10th August 2010, 09:11

True. I don't know why rake isn't working on Mac OS the way it is on Linux. I can only test it on Linux and Windows as I don't have (shell) access to a Mac. So you should stick with the 4.2.0 release for the time being.

Forteen88

10th August 2010, 20:23

When I remux (with mkvtoolnix 4.2.0) some MKV-videos that contains "Cover: Yes / Yes / Yes", then the covers are removed in the remux. Anyone who knows why?

Mosu

10th August 2010, 20:27

What does "Cover: Yes / Yes / Yes" mean? Can you upload such a file somewhere or give me a link where I can download one (torrent is fine)?

Forteen88

10th August 2010, 20:35

What does "Cover: Yes / Yes / Yes" mean? Can you upload such a file somewhere or give me a link where I can download one (torrent is fine)?I think it means that it contains covers (pictures) for the video. I got that info when using MediaInfo on a file. Sry, I don't have a link for that particular MKV, but I can try to find a link on another one with "Covers".

EDIT: I made one myself (with only one picture, so MediaInfo says: "Cover: Yes"), I just added a JPEG-picture as an attachment to a video in Haali's gdsmux, http://www.mediafire.com/?6z4ljwgmg5n67qw
When I remux that file (using mkvmerge), then the "Cover: Yes" is removed, and I guess that the picture is removed too, as the filesize is lower.

Thanks Mosu.

Mosu

11th August 2010, 08:04

After checking such a file before and after muxing I'm certain that the problem is in MediaInfo. mkvmerge now puts attachments at the end but still references them via entries in the meta seek table at the start of the file. That's standard behavior for a Matroska file -- most of those elements (including track headers!) can be located at the end of the file as long as they're indexed at the front. MediaInfo does not seem to follow those indexes to the attachments and therefore it doesn't find the cover image that mkvmerge kept when remuxing.

Please file a bug with MediaInfo. I can explain to them how a proper algorithm should look for finding any of the important (level 1) elements in a Matroska file. Those include track headers, segment information, chapters, tags and attachments.

Forteen88

11th August 2010, 11:28

@Mosu: Thanks, I'll do that.

BTW, MediaInfo seem to be able to detect imagefiles inside a MKV that is muxed with Haali's gdsmux.

Zenitram

12th August 2010, 00:22

After checking such a file before and after muxing I'm certain that the problem is in MediaInfo.

I confirm it.

mkvmerge now puts attachments at the end but still references them via entries in the meta seek table at the start of the file. That's standard behavior for a Matroska file -- most of those elements (including track headers!) can be located at the end of the file as long as they're indexed at the front. MediaInfo does not seem to follow those indexes to the attachments and therefore it doesn't find the cover image that mkvmerge kept when remuxing.

You're totally right.
I follow headers at the end of the file for MP4 files, but I didn't think to check this for MKV because I never saw this kind of file and I don't follow SeekHead/Seek blocks, I stop the parsing when I find the clusters.

I can explain to them how a proper algorithm should look for finding any of the important (level 1) elements in a Matroska file.

Thanks for the proposal, but I already decode SeekHead block, I understand it, I only need to implement the management of this block in my tool, no worry about this.

Could I ask why you put attachements at the end of the file? From my point of view, this is a seek to do (+ another seek to go back to the beginning) for having them, this may be a lot slower with CD/DVD readers or HTTP streaming.

What does "Cover: Yes / Yes / Yes" mean?

This is the way for MediaInfo to display the presence of 4 attachments.
I agree this is not the best way, but MediaInfo is a general purpose tool, not dedicated to MKV, I need find a good generic display for attachments (eg display the name of attachments)

Mosu

12th August 2010, 07:55

Thanks for the proposal, but I already decode SeekHead block, I understand it, I only need to implement the management of this block in my tool, no worry about this.

Good to hear :)

Could I ask why you put attachements at the end of the file? From my point of view, this is a seek to do (+ another seek to go back to the beginning) for having them, this may be a lot slower with CD/DVD readers or HTTP streaming.

I know. There are arguments in favor of and against placing attachments at the end. The ones in favor include easier modification for tools and, more importantly, less stuff to transmit in streaming cases. The ones against include that extra seek (though you usually have to seek to the end in order to read the index anyway) and the situation that even in streaming cases you may need the attachments for playback (e.g. fonts for subtitles). However, no user wants to wait until the 40MB attached files have been downloaded when streaming a file, and seeking on a local medium is comparatively fast. Therefore they're at the end at the moment.

Basically there's no "right" answer, and the placement will most likely change again in the future. mkvmerge will likely use both places and either let the user chose where to put certain attachments or chose automatically based on content type.

Mosu

12th August 2010, 20:38

Use the search function: http://forum.doom9.org/showthread.php?p=1421587#post1421587

BatKnight

12th August 2010, 21:27

Hi,

I've muxed a video-only MKV with a FLAC audio file and placed a -9ms delay to the audio track before muxing.
I've noticed now that I shouldn't have placed the delay because eac3to already delayed the track when decoded the DTS-MA to FLAC.
If load the muxed MKV back to mkvtoolnix and set a positive 9ms delay to the audio, will the delay be correctly removed and this mistake corrected?

Thanks
Bat

Mosu

12th August 2010, 21:30

BatKnight

12th August 2010, 21:37

Not really. mkvmerge's delay option modifies the timecodes of the packets -- so far so good. But packets that would end up with a negative timecode are removed. So in your case your -9 might have caused the very first packet to be dropped during the first remux, and subsequent remuxes can of course not restore that packet.
Thanks for the promptly reply.
In a perfectionist point of view, I lost the first 9ms of audio with this mistake, right? If i remux it with positive delays, what will it insert in the start? Blank audio?
(Not that 9ms would ever be noticed, though...)

Bat

Mosu

12th August 2010, 21:45

mkvmerge won't insert anything with positive delays, it simply adjusts the timecodes. As most (if not all) players use audio for A/V synchronization this is often not such a good idea for big offsets, but with such small values as 9ms it shouldn't be noticeable at all.

sneaker_ger

12th August 2010, 22:29

You will have lost more than 9ms because mkvmerge will drop complete audio frames, as it cannot delete only certain parts of frames. And yes, if you remux with +9ms the delay will be "perfect" again.

BatKnight

12th August 2010, 23:23

You will have lost more than 9ms because mkvmerge will drop complete audio frames, as it cannot delete only certain parts of frames. And yes, if you remux with +9ms the delay will be "perfect" again.
Yes, I now understand that the second remux would restore the delay, but at the cost of permanently loosing the previously dropped audio frames.

Mosu

13th August 2010, 07:57

I said 'packet' and not 'packets' on purpose. For FLAC one packet is typically a lot longer than 9ms -- roughly 96ms for a typical 44.100 Hz two channel file.

toytown

13th August 2010, 12:11

Ive recently been encoding some home movies and just finally got round to muxing them using 4.2, i noticed that as soon as i click the folder with the video files in, the OS (win7) will read the whole file MKV in and the ram will fill up completely to its max (4GB), after about 30-60seconds it will return to normal, if there are more MKV files it will do the same. During this time its impossible to move/copy/delete the file as windows has a lock on it.

The reason for the hang (i believe) is that its trying to extract the thumbnails and failing, i thought the reason could be the header compression option, however if i remux the file using 4.0 or 4.1.1 using default options then the files work perfectly.

Im using the latest haali splitter (with thumbnail extraction off) and ffdshow-tryouts, but i thought win7 had its own filters so that shouldnt matter anyway? Apologies if this is something screwy on my system and not a MKVtoolnix bug.

Mosu

13th August 2010, 13:08

Sounds like header removal, yes.

toytown

13th August 2010, 13:33

Sorry i meant that i originally muxed the files with 4.2 using default options, so header removal would be turned on. These files lock up explorer for some time.

If i take the 4.2 muxed file drop it into 4.1.1 or 4.0 and just click mux, this file will be ok, thumbnails are generated and everything is good. As i understand this file still contains header removal as im just using defaults.

If i take a good file and drop it into 4.2 and just click mux, i get the problems again.

I believe header removal has been in since v4.00 so if this is the case then it must be something else?

Mosu

13th August 2010, 13:40

4.2.0 added header removal for h264 tracks by default. 4.1.0 added header removal for various audio and video formats.

toytown

13th August 2010, 13:57

vmrsss

14th August 2010, 19:29

Hi Mosu,

True. I don't know why rake isn't working on Mac OS the way it is on Linux. I can only test it on Linux and Windows as I don't have (shell) access to a Mac. So you should stick with the 4.2.0 release for the time being.

Can you pls check your rakefiles, configure and options? I have noticed that even if I disable precompiled headers,

./src/common/common_pch.h.gch

is generated all the same, and the compilation breaks immediately there (because the file is included twice).

There is a problem with ./configure, but that's not the only thing, precompiled headers are still active even if I edit config.h to remove the line #define USE_PRECOMPILED_HEADERS 1

Thanks a lot for your help.

Mosu

14th August 2010, 20:21

You're right: --disable-precompiled-headers was not doing what it was supposed to do. Bug in my configure script; fixed in Git. So please 'git pull', run './autogen.sh' followed by './configure --disable-precompiled-headers'. Afterwards you should also 'rake clean' and 'rm -rf rake.d/dependency.d'. Afterwards rake should not build common_pch.h.gch anymore.

There is a problem with ./configure, but that's not the only thing, precompiled headers are still active even if I edit config.h to remove the line

config.h does not control the build process, only the compilation. 'build-config' controls the build process.

vmrsss

14th August 2010, 20:49

You're right: --disable-precompiled-headers was not doing what it was supposed to do.

It works now, I was able to build 'No Talking'. Happy again. :)

Thx a lot for your work, mkvmerge is a great tool

jasonwc

15th August 2010, 05:20

It's a bug in the DivX thumbnailer creator thats installed with the DivX codecs. I checked through the registry to see what ShellEx were being used for MKV files in explorer and found it, i uninstalled the DivX package and the problem is gone, of course i dont get thumbnails but i wasnt bothered about them either.

Im sorry to have wasted your time :(

I can confirm this behavior. Any file with H.264 header compression causes the DivX Explorer filter to crash Explorer on my system as soon as the file is selected. Remuxing with 4.1.1 fixed the issue.

Ritsuka

15th August 2010, 08:09

Is there any real gain in header compression (by real meaning at least 1% of the size of an original file).
Because it seems to be a quite useless and problematic thing.

happ

15th August 2010, 08:28

Brazil2

15th August 2010, 10:18

Is there any real gain in header compression
Almost none, it's a matter of few kBs for GBs large files.

Because it seems to be a quite useless and problematic thing.
Yes it is. That's why many and more and more people don't understand why it's enabled by default.
There are actually more cons than pros for this useless and annoying feature.

Brazil2

15th August 2010, 10:19

Files (x264 video, AC3 or DTS audio) muxed with 4.2.0 cause WD Live TV to stuck. Restarting system (cut of and on power circuit) and remuxing with an earlier version of mkvtoolnix fixed the issue. I can confirm Explorer crash caused with DivX explorer filter, too.
http://www.bunkus.org/videotools/mkvtoolnix/faq.html#header_removal_compression
and
http://forum.doom9.org/showthread.php?t=155976

sneaker_ger

15th August 2010, 17:30

Why is the Playstation 3 on that list if it does not even support Matroska to begin with? If some streaming softwares can't handle it, they should be listed.

Mosu

15th August 2010, 17:50

Because someone mentioned it to me, and I have no clue about what the PS3 supports in the first place :)

sneaker_ger

15th August 2010, 18:11

I also tried MPC from 2006: no problems with H.264+AC3. I think that you probably mixed it up with the "default values" issue.

/edit: newer mplayer versions also seem to work for me (at least the builds from here (http://oss.netfarm.it/mplayer-win32.php))

jasonwc

17th August 2010, 05:33

eac3to 3.2.3 has been updated to support demuxing MKVs with header compression enabled.

Unfortunately, I don't think we'll see a fix for the DivX explorer integration dll.

dejong12

17th August 2010, 14:52

If I try to append subs, mkvmerge crashes with error 3. What's the problem?

Mosu

17th August 2010, 14:54

Details, please.

dejong12

17th August 2010, 15:17

Details, please.
PM'ed you.

Snowknight26

19th August 2010, 02:28

Any chance of adding *.eac3 to the list of all supported media types when opening files? And how about setting the default window location of the muxing progress form to the center of the parent?

Mosu

19th August 2010, 07:55

Probably to the former, no to the latter (I'm not opposed to it, but you know, lack of time etc).

Tomir

19th August 2010, 09:26

4.2.0 isn't outputting ASS files for me. Using latest aegi but don't think that matters anything.

Mosu

19th August 2010, 09:32

4.2.0 isn't outputting ASS files for me. Using latest aegi but don't think that matters anything.

Quoting myself in this case:

Use the search function: http://forum.doom9.org/showthread.php?p=1421587#post1421587

heldchen

22nd August 2010, 16:51

i understand there were some discussions already regarding the use of "und" vs "eng". my issue with this is a bit different, i think: if i specificially instruct mkvmerge to set a track language to "eng", i kinda expect it to do so - instead, the track is added as "und", and i have to change this manually to "eng" using the header editor.

while i have no problem with mkvmerge using "und" when no language is specified for a track, i do not understand its current behaviour...

Mosu

22nd August 2010, 16:54

i understand there were some discussions already regarding the use of "und" vs "eng". my issue with this is a bit different, i think: if i specificially instruct mkvmerge to set a track language to "eng", i kinda expect it to do so - instead, the track is added as "und", and i have to change this manually to "eng" using the header editor.

No, that's not what happens. The program you use for playback/information simply does not support default values. Please read http://www.bunkus.org/videotools/mkvtoolnix/faq.html#default_values for an explanation.

heldchen

22nd August 2010, 17:16

i understand that the default value (i.e. an *unset* value) should be considered english, and i'm fine with that. but i actually do set a value, which means i do not want to use a/the default value. whether the value i set is "ger", "eng", "und" or anything else shouldn't matter to mkvmerge, as i specifically instruct it to use it.

right now mkvmerge sees "eng" as the value and thinks "oh, 'eng' is set, so he probably doesn't want a value, i'll just leave it unset" which is wrong. and following this logic, the mmg header editor also would have to do the "eng" -> unset tranform, which it doesnt.

Mosu

22nd August 2010, 17:23

right now mkvmerge sees "eng" as the value and thinks "oh, 'eng' is set, so he probably doesn't want a value, i'll just leave it unset" which is wrong.

No, it isn't. Semantically it's exactly the same. A player has to treat both cases as identical (element present & set to 'eng' vs. element not present at all). Due to technical reasons I will not change this behaviour (it's related to WebM files amongst other things).

Also mmg's settings are not 'enforce this' kind of settings. Neither mmg nor mkvmerge is designed that way.

and following this logic, the mmg header editor also would have to do the "eng" -> unset tranform, which it doesnt.

No, the header editor is in fact an enforcing thingy, unlike mmg. Think of it as as editing header values directly in the file and of mmg+mkvmerge as the 'filtering' version.