mkvtoolnix 4.1.1 released

[issa]

NEED HELP!!!
I try to merge a movie with 3 avi files and 3 srt subtitle files into a
single mkv file using mmg with append function.
However, after finished merging. I found only first two srt files get merge into the mkv file. I extract the the subtitle form the mkv file and found the last subtitle is same as the last subtitle in the second srt file. The whole 3rd srt file are missing.
The video and audio are pefectly merged.
Is there any limitation on mkvmerge for srt supporting?

[Mosu]

No, there isn't. What's the command line?

[akupenguin]

As far as I know there's no mpeg codecs where b-frames can be timed after the next P frame.
H.264 allows arbitrary frame orders. It's not based on frame types at all, even the IDR-frame doesn't have to be the first frame in display order. A frame could be decoded at one time, and then displayed 500 frames later.
Now, there's an optional field in the SPS that says how much buffering a decoder will need to do, and typically it's only 1 or 2 frames. But that's only the typical case, not the limit.

[bob0r]

Hmm, sounds like a serious memory leak. I'll have to see if I can find some other EVO which triggers this memory leak.

Again.... i think this is a problem with LARGE files.... rather than a file type:

Again my BBC-HD H.264 MBAFF file

mkvmerge v2.0.2 ('You're My Flame') built on Mar 8 2007 16:56:40
'G:\cap\test.h264': Using the AVC/h.264 ES demultiplexer.
'G:\cap\test.ac3': Using the AC3 demultiplexer.
Track 0 of 'G:\cap\test.h264': Extracted the aspect ratio information from the MPEG-4 layer 10 (AVC) video data and set the display dimensions to 1964/1080.
'G:\cap\test.h264' track 0: Using the MPEG-4 part 10 ES video output module.
'G:\cap\test.ac3' track 0: Using the AC3 output module.
The file 'I:\cap\test.mkv' has been opened for writing.
'die' called: common.cpp/saferealloc() called from file src/common/common_memory.cpp, line 33: realloc() returned NULL for a size of 204220 bytes.

test.h264 11.6 GB (12,551,775,186 bytes)
test.ac3 244 MB (256,423,415 bytes)

Haali's muxer has problems with big files also....

Shall i upload these files so you guys can test and fix this once and for all?

[Mosu]

I'd really appreciate that. I've tried getting my hands on such big EVO files but without success so far :(

[bob0r]

This is from a BBC-HD .ts file, also good? upload to that ftp? Mind if i rar it?

[issa]

Mosu,

I found the problem, and I had temp. fix for that.
Wait for your final fix on it.

[Mosu]

This is from a BBC-HD .ts file, also good? upload to that ftp? Mind if i rar it?

Yes, to my FTP server, please. You can surely RAR it.

[Mosu]

Issa: Thanks for the patch. I've only tried it with two or three files here myself, but it's OK for them (and definitely not OK without the patch), so I'm including it.

Here's a current build: http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.0.2-build20070312-1.rar

[Okraml]

I got a sample of an .avc file (20MB) that plays fine standalone, but not after muxing into a .mkv. Cause i have troubles uploading to your ftp, you can download the testfile here (http://depositfiles.com/files/690412).

:-) Okraml

[aabxx]

Taken from matroska-devel, oct. 2005 http://lists.matroska.org/pipermail/matroska-devel/2005-October/002756.html
***
- The Frames in the SimpleBlock have no duration. That means SimpleBlock is not suitable for VFR content (VFR video or Vorbis). Or we could fall back in using BlockGroup when the duration of the frames are not the default ones...
***


Does this mean --engage use_simpleblock should not be used when muxing ogg vorbis?

[Mosu]

Does this mean --engage use_simpleblock should not be used when muxing ogg vorbis?

No. This is not a problem due to two reasons:

Matroska specs say that the duration of a (simple) block is either the value of the BlockDuration element if present, or the value of the track's DefaultDuration element or the difference to the next block of the same track if neither a) nor b) is given. For Vorbis mkvmerge does not write a DefaultDuration element meaning that the duration is always the difference of the current and next timecodes for this track which is perfectly fine with simple blocks.
If a default duration is given and the current packet's duration is different than the default duration then mkvmerge writes a normal block, even if "--engage use_simpleblock" is turned on.

[Mosu]

I got a sample of an .avc file (20MB) that plays fine standalone, but not after muxing into a .mkv. Cause i have troubles uploading to your ftp, you can download the testfile here (http://depositfiles.com/files/690412).

:-) Okraml

That's an interesting file. MP4Box cannot import it correctly either (same playback problems as the Matroska file created with mkvmerge). Is there another application that can actually turn this file into a playable MP4 file?

[Okraml]

That's an interesting file. MP4Box cannot import it correctly either (same playback problems as the Matroska file created with mkvmerge). Is there another application that can actually turn this file into a playable MP4 file?

MP4Creator doesn't produce playable mp4 files too. But i got another testfile for you here (http://depositfiles.com/files/692849).

:-) Okraml

[issa]

I got a ogm/avi file have the audio track 0x674f when play with mplayer, and it can not play the audio. When I import it to mmg, it display unknown type. I found out that it is OGG_VORBIS_1. How can I force the mmg to set the fourcc of the audio track, since the option panel is gray out.

[zgx]

I’m not sure this is the right thread but I’m badly in need of some Matroska muxing help.

I want to put a VC-1 video stream and a DD+ stream from a HD-DVD into a Matroska container. That I have done with the help of gdsmux and mkvmerge but the video seams to play too fast so I get serious audio sync problems. I have read some things about timecode files and I have tried to include a timecode file that looks like this (with the video stream):

# timecode format v1
assume 23.976

That didn’t help so I’m wondering if anyone here has any idea how I could get it to work properly?

[madshi]

I’m not sure this is the right thread but I’m badly in need of some Matroska muxing help.

I want to put a VC-1 video stream and a DD+ stream from a HD-DVD into a Matroska container. That I have done with the help of gdsmux and mkvmerge but the video seams to play too fast so I get serious audio sync problems. I have read some things about timecode files and I have tried to include a timecode file that looks like this (with the video stream):

# timecode format v1
assume 23.976

That didn’t help so I’m wondering if anyone here has any idea how I could get it to work properly?
I don't know gdsmux, but mkvtoolnix doesn't yet support VC-1 muxing. Personally, I'm using Haali's Media Splitter and Haali's Matroska Muxer to mux VC-1 streams into MKV and that works perfectly fine for me.

[zgx]

I don't know gdsmux, but mkvtoolnix doesn't yet support VC-1 muxing. Personally, I'm using Haali's Media Splitter and Haali's Matroska Muxer to mux VC-1 streams into MKV and that works perfectly fine for me.Thanks I will give it a try. What makes it extra tricky is the DD+ as I don't think Haali's Muxer supports it yet.

I'm also thinking there could be something wrong with my playback setup. I get the same problems when I try to play a EVO file in ZoomPlayer.

[madshi]

Thanks I will give it a try. What makes it extra tricky is the DD+ as I don't think Haali's Muxer supports it yet.
Haali's latest version does fully support DD+ !

[Mosu]

I got a ogm/avi file have the audio track 0x674f when play with mplayer, and it can not play the audio. When I import it to mmg, it display unknown type. I found out that it is OGG_VORBIS_1. How can I force the mmg to set the fourcc of the audio track, since the option panel is gray out.

It's not possible. If mkvmerge says that a track is unknown or unsupported, then it is just that, not supported. Especially Vorbis-in-AVI. That's about the worst possible way of storing Vorbis. It's inefficient, completely hacky (because Vorbis is both variable frame rate and variable sample rate). I will never support it.

[dragonle87]

Hi, I have quite a few mkv files with audio out of sync when storing xvid to native mpeg-4 asp. The weird thing is all of these files play perfectly fine in mkv with vfw hack. So basically, is there a way to revert back the changes? If not, can you make it available in the next release? Cause I don't like going thru every single one of them to fix synchronization when they are originally in sync prior to muxing. You know, kind of like how you reintroduced the "--engage allow_avc_in_vfw_mode" hack, make a similar feature like "--engage allow_asp_in_vfw_mode" hack or "--unengage native_mpeg-4" ...well something to that effect. The crappy thing is I don't have the original a/v files prior to muxing in mkv nor do I like the fact of going thru the whole encoding process again.

btw, for playback, I use MPC (internal filters disabled) + ffdshow + Haali's splitter.

[Mosu]

Hi, I have quite a few mkv files with audio out of sync when storing xvid to native mpeg-4 asp. The weird thing is all of these files play perfectly fine in mkv with vfw hack. So basically, is there a way to revert back the changes?

No.

If not, can you make it available in the next release?

No, sorry.

[issa]

It's not possible. If mkvmerge says that a track is unknown or unsupported, then it is just that, not supported. Especially Vorbis-in-AVI. That's about the worst possible way of storing Vorbis. It's inefficient, completely hacky (because Vorbis is both variable frame rate and variable sample rate). I will never support it.

I found out that the file is ogm/ogg with renamed to avi extension.
However, I think the 0x674f is code OGG. Why the mmg said the audio track unknown? I have another ogm file that the mmg can detect the audio track as vorbis.

[Mosu]

I found out that the file is ogm/ogg with renamed to avi extension.
However, I think the 0x674f is code OGG. Why the mmg said the audio track unknown? I have another ogm file that the mmg can detect the audio track as vorbis.

Real OGM files with properly muxed Vorbis tracks are fully supported. AVI with OGG/Vorbis inside are not supported, and will not be supported. OGM files which use the ACM mode of storing audio (the same mode that you can store MP3 in OGM) for Vorbis are the same case as AVI with Vorbis -- no, they're even worse. And won't be supported either.

[issa]

Real OGM files with properly muxed Vorbis tracks are fully supported. AVI with OGG/Vorbis inside are not supported, and will not be supported. OGM files which use the ACM mode of storing audio (the same mode that you can store MP3 in OGM) for Vorbis are the same case as AVI with Vorbis -- no, they're even worse. And won't be supported either.

That's mean the 0x674f is the ID of OGG for ACM mode?

[foxyshadis]

Since these brain-dead files can't be that common, why not just use vdubmod or avimux gui to extract the audio track? You'll have to unencapsulate it then (probably by just deleting the header) and it should work after that.

[issa]

Since these brain-dead files can't be that common, why not just use vdubmod or avimux gui to extract the audio track? You'll have to unencapsulate it then (probably by just deleting the header) and it should work after that.

Thanks, I forgot the basic way...

:stupid:

[LeMoi]

If a stretch AND a delay is applied on a sub track, which one is first applied ?

[Rectal Prolapse]

I am having trouble importing SRT files created by Pelican9's Supread.exe tool - is there something that needs to be added to the SRT file to make it recognizable by mkvmerge?

It starts and ends like this:


1
0:01:48.041 --> 0:01:50.442
Bloody kids.

2
0:02:36.890 --> 0:02:40.554
How fastidious you've become,
Wormtail.

...

1508
2:23:00.772 --> 2:23:04.538
-Harry will, won't you?
-Yeah. Every week.

1509
2:37:01.345 --> 2:37:03.336
[ENGLlSH]


Thanks.

[Mosu]

1
0:01:48.041 --> 0:01:50.442
Bloody kids.

The timestamps have to use "," as the decimal separator, not ".".

Edit: Or you could just use this build: http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-2.0.2-20070316-1.rar

[Mosu]

If a stretch AND a delay is applied on a sub track, which one is first applied ?

If you mean the two components of the --sync switch: First the delay, then the stretch factor. The --delay argument is added last.

[Rectal Prolapse]

Thanks Mosu, MKVMergeGUI recognized it!

[Okraml]

@Mosu
Did you found out, whats wrong with the videofiles from this (http://forum.doom9.org/showthread.php?p=969420#post969420) and this (http://forum.doom9.org/showthread.php?p=969867#post969867) post?

Cause Haali Matroska Muxer doesn't work as well, i will post there too.

:-) Okraml

[Mosu]

No, not yet. I'll post when I know more, but that won't be for a couple of days.

[DeepBeepMeep]

I don't know if this has been already reported, but I have trouble merging a 3 part files that has been previously split using mkvmerge with the "link" options.

The file here is a matroska with MPEG2 + 2 AC3 audio tracks
Once the first file has been processed, I get a:
----------
'die' called: fref_packet == NULL. Wanted fref: -125000000. Contents of the queue:
Packet 0, timecode -1841054272, bref -1924054272, fref -1799054272
Packet 1, timecode -1776054272, bref -1, fref -1
Packet 2, timecode -1776054272, bref -1, fref -1
Packet 3, timecode -1744054272, bref -1, fref -1
Packet 4, timecode -1744054272, bref -1, fref -1
Packet 5, timecode -1712054272, bref -1, fref -1
Packet 6, timecode -1712054272, bref -1, fref -1
Packet 7, timecode -1680054272, bref -1, fref -1
Packet 8, timecode -1680054272, bref -1, fref -1
Packet 9, timecode -1674054272, bref -1799054272, fref -1
Packet 10, timecode -1758054272, bref -1799054272, fref -1674054272
Packet 11, timecode -1716054272, bref -1799054272, fref -1674054272
Packet 12, timecode -1648054272, bref -1, fref -1
Packet 13, timecode -1648054272, bref -1, fref -1
Packet 14, timecode -1632054272, bref -1, fref -1
Packet 15, timecode -1716054272, bref -1632054272, fref -125000000
Packet 16, timecode -1674054272, bref -1632054272, fref -125000000
Packet 17, timecode -1616054272, bref -1, fref -1
Packet 18, timecode -1616054272, bref -1, fref -1
Packet 19, timecode -1584054272, bref -1, fref -1
Packet 20, timecode -1584054272, bref -1, fref -1
Packet 21, timecode -1552054272, bref -1, fref -1
Packet 22, timecode -1552054272, bref -1, fref -1
Packet 23, timecode -1507054272, bref -1632054272, fref -1
----------

[Mosu]

Negative timecodes? Oh oh... Looks like mkvmerge has overflow issues somewhere. Can you give me some more details about the file? Like duration, how you created it etc.

[DeepBeepMeep]

If I rememeber correctly the files were created using mkvmerge with elementary streams. The MPEG2 stream has been extracted from a Bluray Disk using the xport tool. The movie is 1:30 minutes and spans around three 4.5Gb Files.
Note I have managed to merge them using Haali filter and Haali matroska filter so it seems the files are not corrupted.

I hope this helps

[ToS_Maverick]

@mosu: this errors look quite familiar to me, remeber :D

[Mosu]

Well, partially. In your case there were no negative timecodes involved, even though the error message is the same. Therefore the reason may or may not be the same.

[LeMoi]

If you mean the two components of the --sync switch: First the delay, then the stretch factor. The --delay argument is added last.

Is there a way to stretch, THEN delay, via command line ?

[Mosu]

No, there isn't.

[bob0r]

@Mosu

When will it be possible to mux .mkv to .mkv and fix nal-size to 4?

I muxed all my .mkv with nal-size 3, but Cyberlink H.264 decoder wont decode the video (so the file just stops at the beginning)

[Mosu]

It's done when it's done. Sorry, I can't give you a date.

[LeMoi]

No, there isn't.
Can I make it a feature request ? :)

[Mosu]

Sure you can, but it'll be veeery low on my priority list. It'll be best if you create a new bug in my Bugzilla system and set the severity to enhancement. That way I won't forget about it.

[delacroixp]

I've been encoding "Band of Brothers" an Mpeg-2, 720x576 (PAL) 16:9 movie... @ full 720x576 resolution...
using H264, AutoMKV, the ConstantQuality-CRF profile set to Q22 and the MKV container.

It encodes beautifully but refuses to play back at 1024x576, 16:9 DAR...
I can manually adjust my Zoom Player to 16:9 DAR and all is good.

AutoMKV does have modified AR and Anamorphic Muxing Options... but they don't seam to have any effect...
Buzzqw (http://forum.doom9.org/showpost.php?p=974816&postcount=1544) recommended that I try here... perhaps a little hands-on muxing with MkvMerge could do the trick.

Please help !

:thanks:


:) :D :eek:
Pascal

[J_Darnley]

Use the following switch with mkvmerge, but of course replace <track> with the number for the video track.

--display-dimensions <track>:1024x576

[honai]

I get the following errors/warnings:


Warning: pr_generic.cpp/generic_packetizer_c::add_packet(): timecode < last_timecode (00:59:30.600 < 00:59:30.667) for 1 of '...\Serenity\part1.mkv'. This should not have happened. Please contact the author Moritz Bunkus <moritz@bunkus.org> with this error/warning message, a description of what you were trying to do, the command line used and which operating system you are using. Thank you.

Warning: pr_generic.cpp/generic_packetizer_c::add_packet(): timecode < last_timecode (01:22:38.595 < 01:22:38.662) for 1 of '...\Serenity\part2.mkv'. This should not have happened. Please contact the author Moritz Bunkus <moritz@bunkus.org> with this error/warning message, a description of what you were trying to do, the command line used and which operating system you are using. Thank you.

Warning: pr_generic.cpp/generic_packetizer_c::add_packet(): timecode < last_timecode (01:48:27.859 < 01:48:27.926) for 1 of '...\Serenity\part2.mkv'. This should not have happened. Please contact the author Moritz Bunkus <moritz@bunkus.org> with this error/warning message, a description of what you were trying to do, the command line used and which operating system you are using. Thank you.


Command-line:


"mkvmerge" -o "...\Serenity\full.mkv" --language 1:eng --track-name "1:Video VC-1 1080p" --display-dimensions 1:1920x1080 -d 1 -A -S ...\Serenity\part1.mkv -d 1 -A -S +...\Serenity\part2.mkv --track-order 0:1 --append-to 1:1:0:1


(where "..." denotes the respective file path)

Source was demuxed with Haali's Splitter and Matroska Muxer straight from the .EVO files. Using Windows XP SP2.

[Mosu]

Concatenating h264 video is buggy at the moment, and I don't know when I'll be able to fix this.

[madshi]

@honai, here's the answer to your post:

http://forum.doom9.org/showthread.php?p=964902#post964902