mkvtoolnix 1.6.5 is out [Archive] - Page 2

fuxor123

30th December 2005, 03:38

Mosu

30th December 2005, 09:51

I just encoded a transport stream and would like to mux the ac3 audio file with the video file. I got the ac3 with DVD2AVIT3. Now when i check the properties of the audio file before muxing it with mkvtoolnix with mpc it tells me that its a 6 channel audio. But when i check the properties of the muxed final file with mpc again it states that the audio is 2 channel stereo.
Is this just my computer doing something wrong or am i missing some important setting when muxing?

You can't influence the basic stream settings (sample rate, number of channels etc) with settings, so you're not doing anything wrong. Please upload the first 200 KB of that AC3 file to my FTP server so that I can take a look at it.

fuxor123

30th December 2005, 13:08

It's pretty weird. Afterwards I converted the audio file that i demuxed directly from the ts' and that's supposed to be stereo to another ac3 with same bitrate and 5.1 channels with besweet. and if i mux that resulting ac3 with the video mpc says that its a 6 channel audio.
Nonetheless I'll upload the pure unchanged ac3 that came directly from the ts and the one i "changed" with besweet...
Thanks for looking at it.

Doom9

4th January 2006, 11:56

another very noobish question from me: can mkvmerge handle raw MPEG-4 (A)SP streams? xvid_encraw only writes raw output...

Elias

4th January 2006, 12:00

another very noobish question from me: can mkvmerge handle raw MPEG-4 (A)SP streams? xvid_encraw only writes raw output...You mean as in the cmp (or was it cpm?) container? Or mp4v? I can give it a try and check in an hour or when I have time.

Doom9

4th January 2006, 13:04

no container.. raw streams (like when you extract one from an mp4 via mp4box or write a raw file via mencoder and -of rawvideo)

Mosu

4th January 2006, 17:38

another very noobish question from me: can mkvmerge handle raw MPEG-4 (A)SP streams? xvid_encraw only writes raw output...

No, sorry, no raw video streams of any kind at the moment.

Kurtnoise

4th January 2006, 19:21

@Doom9: you could mux raw to mp4 with mp4box first then mp4 to mkv with mkvmerge...

Doom9

4th January 2006, 23:41

@Doom9: you could mux raw to mp4 with mp4box first then mp4 to mkv with mkvmerge...Of course I could.. but the sheer thought makes me shudder.. mux so that you can mux again.. it feels so pointless somehow (you remember me saying the same about getting raw avc streams into mkv.. not even sure if that's possible now). The thing is, but xvid commandline encoder tools only provide raw output.

Egh

5th January 2006, 20:47

Of course I could.. but the sheer thought makes me shudder.. mux so that you can mux again.. it feels so pointless somehow (you remember me saying the same about getting raw avc streams into mkv.. not even sure if that's possible now). The thing is, but xvid commandline encoder tools only provide raw output.

I agree. In fact there're some ways to do so even w/o mp4box (which i found very buggy and glitching). 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?

Also, about avc raw streams. Quite easy, but a bit too dirty to do so :) Use avc2avi tool (it takes avc raw stream and outputs avc-in-avi). The only problem with it is that if you mux the avi into mkv, you'll get it in VfW mode, which all the matroska gurus oppose :)

foxyshadis

6th January 2006, 00:28

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

Doom9

6th January 2006, 00:36

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

Isochroma

6th January 2006, 01:03

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

6th January 2006, 08:46

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

6th January 2006, 08:47

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

6th January 2006, 20:37

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

11th January 2006, 10:31

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

11th January 2006, 11:08

mkvtoolnix doesn't support speex files...

buzzqw

11th January 2006, 13:17

Ouch ...

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

BHH

Kurtnoise

11th January 2006, 16:03

how mux mp4 and speex in any other container ? :thanks:
you can't...or maybe wrap speex stream into AVI via ACM codec. But I'm not sure about that.

Egh

12th January 2006, 23:48

Mosu

13th January 2006, 08:15

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

13th January 2006, 22:43

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

16th January 2006, 14:02

Mosu

19th January 2006, 15:27

LeMoi

19th January 2006, 21:17

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

Mosu

27th January 2006, 09:15

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 :o

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

27th January 2006, 09:18

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

27th January 2006, 10:26

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

27th January 2006, 13:59

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.

robU*4

27th January 2006, 22:02

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 :)

When doing something like that, could you add it in the mkvtoolnix description in the matroska header ? This way we can track matroska files that we created with dubious settings. :)

Haali

27th January 2006, 23:21

and propagate it further when remuxed

bond

30th January 2006, 20:40

i already told mosu via irc about this but i post this here again so i dont forget it :D

i think i have found a bug in mkvmerge related to creating native mpeg4 from mp4. it seems mkvmerge has problems around i-frames, as it seems to wrongly detect the timestamps and the frametype there.
this only happens right around keyframes. the timestamps of the rest of the stream are perfectly fine

first of all storage order should be PIPBPB but mkvmerge writes PIBBPB so it thinks one P to be a B
the next error is that the display order should be PIBPBP but mkvmerge signals timestamps for PBBIBP

i double checked it with 1) what xvid reports it has written 2) what mp4box writes from the raw xvid stream 3) what xvidcli's native mpeg4 mkv writes and all show mkvmerge to be wrong

i have this on a stream with 2 keyframes and around both there is this problem, get the sample here (http://home.pages.at/bond_/mkvmerge.7z)

thana

7th February 2006, 02:04

hi mosu, i found a .mov which mkvmerge can't identify:
Error: Quicktime/MP4 reader: Invalid chunk size 0 at 20.
it plays fine with mplayer and quicktime, tracks are h264 and 'twos' (big endian 16bit pcm audio). i uploaded the first 4MB to your ftp (h264_twos.mov), i hope that's enough.

HookedOnTV

9th February 2006, 18:11

So is raw AVC/H.264 on the radar?

Mosu

9th February 2006, 18:21

Not really, sorry.

stax76

10th February 2006, 22:37

Can I use strings like 'русский' for --track-name? Using Haali splitter and Zoom Player displays '????????', same problem with MP4Box.

Mosu

10th February 2006, 22:46

With mmg this should work. On the command line you'll also have to use --commandline-charset before --track-name.

stax76

11th February 2006, 01:03

With mmg this should work. On the command line you'll also have to use --commandline-charset before --track-name.

My chars 'русский' translate to 'russian', I get this chars from .NET and the values are > 1000. maybe on a russian system it would return chars covered by cyrillic 8859-5, I don't know if the unicode > 1000 chars could be converted to 8859-5 < 255 chars. Does mkv/mkvmerge not support unicode chars? I'm afraid I'm a bit clueless about text encoding. :(

Egh

11th February 2006, 02:49

My chars 'русский' translate to 'russian', I get this chars from .NET and the values are > 1000. maybe on a russian system it would return chars covered by cyrillic 8859-5, I don't know if the unicode > 1000 chars could be converted to 8859-5 < 255 chars. Does mkv/mkvmerge not support unicode chars? I'm afraid I'm a bit clueless about text encoding. :(

Windows should return cyrillic either as Win-1251 CP (one-byte) or as unicode. (In all the windows functions that is).

I tried just now (using mmg and typing in Русский as a track name). The string in the muxed mkv itself is represented as UTF-8. This is most likely inner conversion in the GUI of MMG itself, with CLI it can be different, I suppose. And with mmg muxed file the track names are displayed correctly (haali splitter + mpc). Maybe you just don't have fonts in the system to display it? I'd suggest you check the mkv with mkvinfo -g first, see how the trackname is written in it.

Besides, where did you dig out "iso 8859-5" standard? :O Win1251 for single-byte or Unicode for real things. Anything else for cyrillic (DOS CP866, KOI8-R and other monstrocities) should be scrapped, though they still have usage (mainly on obsolete systems).

stax76

11th February 2006, 14:55

And with mmg muxed file the track names are displayed correctly (haali splitter + mpc).

I can confirm this so I have to ask the Zoom Player author what's the problem.

Besides, where did you dig out "iso 8859-5" standard?

http://de.wikipedia.org/wiki/ISO_8859

For Windows you are right it's 1251 (I couldn't remember).

Last but not least thanks to Egh and Mosu.

Egh

12th February 2006, 00:15

I can confirm this so I have to ask the Zoom Player author what's the problem.
http://de.wikipedia.org/wiki/ISO_8859

For Windows you are right it's 1251 (I couldn't remember).

Well I suspected that it could be either your OS or Zoom Player not showing the tracknames in other languages. As for 8859 and so on, well, I know all encodings for cyrillics. My point was that noone uses iso-8859-5 in practice :P

issa

12th February 2006, 05:32

Here is the latest CVS/SVN Build (msvc unicode),

URL: http://rapidshare.de/files/13076901/mkvtoolnix-20060211-msvc.7z.html

Tima

14th February 2006, 15:20

I have russian Windows, and russian strings work ok (MPC + Haali MS) without changing the default charset..

Booji Boy

20th February 2006, 22:02

When I do the following (created with mkvmerge gui):

"mkvmerge" -o "My home movie.mkv" -a 1 -d 0 -S My home movie part1.avi -a 1 -d 0 -S +My home movie part2.avi --track-order 0:0,0:1 --append-to 1:0:0:0,1:1:0:1

I get the following error:

Error: The track number 1 from the file 'My home movie part2.avi' cannot be appended to the track number 1 from the file 'My home movie part1.avi' because the formats do not match.

It is a DTS soundtrack... (of course in both cases). :( is DTS not fully supported or are there some limitations or is there something wrong with my soundtracks? I found nothing at your bugtracker regarding DTS and the docs says nothing about DTS limitation within mkvmerge.

I get the same error when merging other videos which have DTS soundtracks.

Mosu

20th February 2006, 22:23

For DTS this means that either the sample rate of the number of channels do not match. This must be the case because in a Matroska file a single track must always have the same sample rate / the same number of channels.

If those two actually match then it might be a bug in mkvmerge.

Mosu

20th February 2006, 22:29

Ok forget what I just wrote. That would have been the case if the error message read "...because the track parameters do not match".

I think that concatenation of DTS-in-AVI is simply not supported at the moment because there's still some code missing for that. DTS has never been used by a lot of people, and I don't even have a single DTS-in-AVI file...

Booji Boy

20th February 2006, 22:53

Ok, thanks for the quick answer. Then I'll simply postpone editing those videos until it gets implemented. Or maybe I'll try to find a way of merging the demuxed DTS tracks "outside" and "by hand"...

Btw, nice work. MMG is really saving a lot of time.

multicone

21st February 2006, 19:46

Try making MKVs from the AVIs first, then concatenate the MKVs and make a new MKV. This should work.

Booji Boy

21st February 2006, 23:23

Thx, for that idea.

But I tried it and I got the exact same error when joining the mkv files. Interestingly though there was a warning during remuxing the second movie:

Warning: dts_packetizer: skipping 622 bytes (no valid DTS header found). This might make audio/video go out of sync, but this stream is damaged.

Let's see if VirtualDubMod can demux the DTS tracks and whether I can mux them back into the movie after that.

EDIT: Now when I use those two dts files as sources for audio instead of the same streams inside the avis/mkvs joining and remuxing everything together works. I get full "DTS Frame Header Information:" for the second dts stream when it is openend before remuxing starts and it seems to be a ok header, but when the dts stream #2 is finally loaded during the muxing process the warning pops up again.

I also found the reason for the invalid start of the second movie's audio stream - the movie wasn't split very well. I think the second part does not start with a keyframe.