mkvtoolnix 1.6.5 is out

[foxyshadis]

mkvmerge has the --engage native_mpeg4 flag, although of course raw->avi->mkv is no better (slightly worse...) than raw->mp4->mkv. ;_;

[Doom9]

I've always been wondering, is there an overhead difference between VfW compatibility mode and native mode?

[Isochroma]

Indeed there is, at least for h.264 MP4 vs. h.264 in AVI. Playback on my machine takes significantly more cpu in AVI mode, and the usage spikes are much higher. A file that plays back ok in native mode often stutters slightly in AVI mode.

[Mosu]

Originally Posted by foxyshadis

mkvmerge has the --engage native_mpeg4 flag, although of course raw->avi->mkv is no better (slightly worse...) than raw->mp4->mkv. ;_;

--engage native_mpeg4 is mis-named. It only handles MPEG-4 part 2 (DivX/XviD and the likes), not part 10 (AVC).

[Mosu]

Originally Posted by Egh

But would be good if mkvtoolnix supported raw input as well. In any case, mkvextract can extract to raw streams so why not to use them as input?

Of course it would be good, and I'm working on it from time to time. But parsing AVC ES is WAY more complicated than writing it if the frames are already packaged (as they are in a Matroska file): just write the header (00 00 00 01), write the length, write the packet, done.

[Egh]

Originally Posted by foxyshadis

mkvmerge has the --engage native_mpeg4 flag, although of course raw->avi->mkv is no better (slightly worse...) than raw->mp4->mkv. ;_;

In some aspect it's much better to use avi though -- you can use vdub on it. In fact I use that to patch the files without fully reencoding them. And doing it thru avi for test releases is usually the most convinient way.

Though using splitting/combining in mkvmerge is almost as convinient (but usually still need avi file to determine exact GOPs to reencode).

[buzzqw]

using this string for muxing (generated by mmg)

mkvmerge.exe -o "D:\DVDMAGIC\movie.mkv" -d 1 -A -S D:\movie.mp4 -D -A -S "D:movie T01 3_2ch 384Kbps DELAY -23ms.spx" --track-order 0:1,1:0

i got this error

Warning: 'D:\movie T01 3_2ch 384Kbps DELAY -23ms.spx': No tracks will be copied from this file. This usually indicates a mistake in the command line.

the file is generated by beswet ,the header of speex files is

00000000h: 4F 67 67 53 00 02 00 00 00 00 00 00 00 00 78 71 ; OggS..........xq
00000010h: 00 00 00 00 00 00 E4 89 07 97 01 50 53 70 65 65 ; ......ä‰.—.PSpee
00000020h: 78 20 20 20 73 70 65 65 78 2D 31 2E 31 2E 36 00 ; x   speex-1.1.6.
00000030h: 00 00 00 00 00 00 00 00 01 00 00 00 50 00 00    ; ............P..

but isn't recognized by MMG

Any tips ?

BHH

[Kurtnoise]

mkvtoolnix doesn't support speex files...

[buzzqw]

Ouch ...

.... so... how mux mp4 and speex in any other container ?

BHH

[Kurtnoise]

Originally Posted by buzzqw

how mux mp4 and speex in any other container ?

you can't...or maybe wrap speex stream into AVI via ACM codec. But I'm not sure about that.

[Egh]

Mosu: any key to disable strict check on AVC streams merge? I mean when codec private data is same length but different content.

1.6.0 older builds mux everything fine, and since last build for 1.6.0 and 1.6.5 mkvmerge fails to merge those.

[Mosu]

Originally Posted by Egh

Mosu: any key to disable strict check on AVC streams merge? I mean when codec private data is same length but different content.

1.6.0 older builds mux everything fine, and since last build for 1.6.0 and 1.6.5 mkvmerge fails to merge those.

No, and it doesn't fail, it refuses. I've spent too much time trying to figure out supposed bugs with AVC concatenation that were due to differing codec privates -- cases in which mkvmerge simply cannot concatenate streams correctly. Therefore it refuses to do so in the first place.

[Egh]

Originally Posted by Mosu

No, and it doesn't fail, it refuses. I've spent too much time trying to figure out supposed bugs with AVC concatenation that were due to differing codec privates -- cases in which mkvmerge simply cannot concatenate streams correctly. Therefore it refuses to do so in the first place.

Well I understand that. But why not to include some key "use at your own risk" or something like that? E.g. in my case if i recode into avc op and main ep separately by Nero Recode, last versions of mkvtoolnix refuse to merge those streams. But it works fabulously with 1.6.0 and previous ones. I don't know what's even different in those private_data headers, it's probably some 1 byte difference or so, which doesn't affect merge anyway.

[LeMoi]

When i create an audio file with BeSweet, using aac v2 dll, with "v5" parameter ("Dual Channels"), the infos of the generated aac are not stored correctly when i mux it in an mkv. With MatroskaProp I can see that number of channels is set to 0, and so, Haali splitter can't play the file saying that it has invalid number of channels

[Mosu]

Originally Posted by LeMoi

When i create an audio file with BeSweet, using aac v2 dll, with "v5" parameter ("Dual Channels"), the infos of the generated aac are not stored correctly when i mux it in an mkv. With MatroskaProp I can see that number of channels is set to 0, and so, Haali splitter can't play the file saying that it has invalid number of channels

Please upload such a AAC/MP4 file as I don't have BeSweet. Thanks.

[LeMoi]

See both aac and mkv here :
http://lemoi.fr.free.fr/test_cod/

[Mosu]

Originally Posted by LeMoi

When i create an audio file with BeSweet, using aac v2 dll, with "v5" parameter ("Dual Channels"), the infos of the generated aac are not stored correctly when i mux it in an mkv. With MatroskaProp I can see that number of channels is set to 0, and so, Haali splitter can't play the file saying that it has invalid number of channels

Your file has a serious problem: the "channels" element of all the ADTS headers in the file are set to 0. I've been digging around in the faad2 source code a bit, and in this case faad2 gets the actual number of channels by starting to decode the packet and summing up the channel configuration (number of front/back channels etc).

Unfortunately this is way more than I'm willing to implement in mkvtoolnix. Therefore such files will never be supported properly. I might even refuse to mux them in the first place.

Unless someone provides a patch for mkvtoolnix which implements this.

[Mosu]

Originally Posted by Egh

Well I understand that. But why not to include some key "use at your own risk" or something like that? E.g. in my case if i recode into avc op and main ep separately by Nero Recode, last versions of mkvtoolnix refuse to merge those streams. But it works fabulously with 1.6.0 and previous ones. I don't know what's even different in those private_data headers, it's probably some 1 byte difference or so, which doesn't affect merge anyway.

I will add "--engage override_safety_checks" for this soon. It's a "I know what I'm doing, but don't blame the author" switch. So if playback of such a file fails I'll flat out refuse to give any support

[LeMoi]

Originally Posted by Mosu

Your file has a serious problem: the "channels" element of all the ADTS headers in the file are set to 0. I've been digging around in the faad2 source code a bit, and in this case faad2 gets the actual number of channels by starting to decode the packet and summing up the channel configuration (number of front/back channels etc).

Unfortunately this is way more than I'm willing to implement in mkvtoolnix. Therefore such files will never be supported properly. I might even refuse to mux them in the first place.

Unless someone provides a patch for mkvtoolnix which implements this.

OK no problem, anyway i never use "dual channels", it was just for reporting

[Mosu]

Originally Posted by LeMoi

OK no problem, anyway i never use "dual channels", it was just for reporting

ok, then I won't feel too bad about it I'm just wondering if this is a bug in the encoder software or if '0' is actually a valid setting for ADTS AAC headers... The latter case sounds FUBAR.