MKVToolNix 1.6.0 has been released - Page 8

Liisachan · 28th August 2005, 12:45

Extracting .h264 should work one way or another, but I have no luck so far.
The bottom line is, I will use x264.exe, not VfW. Like Doom9 said, it's pointless to use AVI when transmuxing it into MKV.

Anyway this doesn't work:

Code:

C:\test>avi2raw60 avc.avi avc.m4v
avi2raw60 - mpeg4ip version 1.3.6
avi2raw60: warning: 3 zero length frames ignored
2214 video frames written

It says 3 frames were dropped. I guess because I used 3 consecutive b-frames and apparently avi2raw60 doesn't know the hack used by x264vfw... And even if I ignore the 3 frames mp4box doesn't like the above output.

Code:

C:\test>mp4box -add avc.m4v -new avc.mp4
MPEG-4 Video import - 0 x 0 @ 25.0000 FPS
Indicated Profile: Simple Profile @ Level 1
Import results: 0 VOPs (0 Is - 0 Ps)
Converting to ISMA Audio-Video MP4 file...
Adjusting visual track size to 0 x 0
Saving avc.mp4: 0.500 secs Interleaving

C:\test>mkvmerge -o test.mkv avc.mp4
mkvmerge v1.5.5 ('Another White Dash') built on Aug 21 2005 15:40:13
'avc.mp4': Using the Quicktime/MP4 demultiplexer.
Warning: Quicktime/MP4 reader: Track 201 is missing some data. Broken header atoms?
Warning: 'avc.mp4': No tracks will be copied from this file. This usually indicates a mistake in the command line.

Error: No streams to output were found. Aborting.

I tried mp4creator too. mp4creator is a bit kind, saying "This is not recommended due to the use of b-frames" but in the end it says "mp4creator: video compressor x264 not recognized"...

I asked VLC Player too to transmux my AVI to MP4, but the resulted file was broken. So my impression now is, almost nobody knows the hack used by x264vfw...perhaps the only exception is ffdshow.

Doom9 · 28th August 2005, 12:50

Quote:

avi2raw60 avc.avi avc.m4v

avi2raw60 is ooooold. Download an up-to-date mpeg4iptools package from celtic-druid: http://www.aziendeassociate.it/cd.asp?dir=/mpeg4iptools
Then you're using the wrong extension.. mp4box recognizes the input type by its extension.. raw ASP has to be .m4v, raw AVC must be .264.

Liisachan · 28th August 2005, 13:59

Thanks for the tip, it worked now, after I renamed .m4v to .264
MP4 is 3 frames shorter, but the dropped are the last 3 frames (not the frist 3 frames nor random 3 frames) and lucily they happen to be the sequence of meaningless black frames.

Oh, btw didn't you see this part?

C:\test>avi2raw60 avc.avi avc.m4v
avi2raw60 - mpeg4ip version 1.3.6

It's very new--even newer than the newest version on the page you mentioned (that is 1.3.5 as of writing). I know it was renamed, but celtic_druid's 1.3.6cvs has avi2raw"60"

--edit
I tried 1.3.5 too just in case, but the 3 frames will be dropped no matter what. They are unimportant frames in this case tho.
I've also noticed that I need -fps switch unless the video is 25.0fps.
so, for reference, the commandline I used is:

avi2raw avc.avi raw.264
mp4box -fps 23.976 -add raw.264 avc.mp4
mkvmerge -o output.mkv avc.mp4

stephanV · 28th August 2005, 15:09

The three dropped frames are empty chunks at the beginning of the avi file needed for the b-frame encoding delay and you will lose the last three frames because effectively those frames are never received by your encoding app (again, due to the delay).

Liisachan · 29th August 2005, 01:05

I've suddenly realized that maybe I should use MP4 too even when I'm encoding with XviD, if the final target format is MKV. I think mkvmerge will accept MPEG-4 Part2 Video in MP4 and at least Haali Splitter (and perhaps MPC) will play it too. I should test that later to see the upsides and downsides...

@stephanV: I see. Thanks for info. But can't the encoder (x264) add 3 null frames at the end of the clip when it decides to put the 'empty chunks at the beginning of avi file'?

Mosu · 29th August 2005, 07:47

Quote:

Originally Posted by Liisachan

I've suddenly realized that maybe I should use MP4 too even when I'm encoding with XviD, if the final target format is MKV. I think mkvmerge will accept MPEG-4 Part2 Video in MP4

It does

celtic_druid · 29th August 2005, 08:47

Guess I usually rename avi2raw. I was in somewhat of a hurry Friday night when I compiled/released 1.3.6.

stephanV · 29th August 2005, 10:29

Quote:

Originally Posted by Liisachan

I've suddenly realized that maybe I should use MP4 too even when I'm encoding with XviD, if the final target format is MKV. I think mkvmerge will accept MPEG-4 Part2 Video in MP4 and at least Haali Splitter (and perhaps MPC) will play it too. I should test that later to see the upsides and downsides...

I don't see how it would matter... muxing from MP4 still would use the VFW mode and Native mode is supported from AVI as well. (Mosu can correct me if I'm wrong.

)

Quote:

@stephanV: I see. Thanks for info. But can't the encoder (x264) add 3 null frames at the end of the clip when it decides to put the 'empty chunks at the beginning of avi file'?

It could, but it doesn't.

Note that the empty chunks are placed at encoding start, not end. It's the well known 1 frame in - 1 frame out restriction of VFW that causes it. Basically VirtualDub starts feeding x264 with frames, but x264 needs to buffer to make it possible to encode b-frames. While x264 is buffering it outputs 0 byte frames (or nothing) so 0 byte frames is what VirtualDub will write. When VirtualDub is done feeding x264 all frames it quits, and the frames that are still in x264's buffer will stay forever in Limbo. (those are the missing frames).

So basically 2 things need to be done:

1. VirtualDub needs to know when x264 is finished with buffering, so it starts to write the file at the right time, and
2. VirtualDub shouldn't quit after it is finished feeding all frames, but when x264's buffer has been emptied.

This will probably require a few work arounds on both ends.

I don't consider the empty chunks at the beginning a very big problem though, they can quite easily be removed, and for the last few missing frames... don't care about that either.

But since you are going to MKV, I would seriously consider using x264cli with MKV-output. It saves you quite some steps.

Mosu · 29th August 2005, 10:32

Quote:

Originally Posted by stephanV

I don't see how it would matter... muxing from MP4 still would use the VFW mode and Native mode is supported from AVI as well. (Mosu can correct me if I'm wrong.

)

That's correct. For ASP ( = MPEG-4 part 2) the VfW mode is the default one, regardless of the source container (AVI, OGM, MP4). The native mode is only enabled with "--engage native_mpeg4" or if you're remuxing a native ASP track from a Matroska file.

For AVC things are different.

Liisachan · 29th August 2005, 11:17

Quote:

Originally Posted by stephanV

I don't see how it would matter... muxing from MP4 still would use the VFW mode and Native mode is supported from AVI as well. (Mosu can correct me if I'm wrong.

)

It was just a sudden random thought, and I said maybe. This morning (my time), I was a purist somehow thinking "B-Frames in AVI are evil" after seeing those 3 frames are dropped. Yes, I was kinda shocked, honestly.

Quote:

Originally Posted by Mosu

That's correct. For ASP ( = MPEG-4 part 2) the VfW mode is the default one, regardless of the source container (AVI, OGM, MP4). The native mode is only enabled with "--engage native_mpeg4" or if you're remuxing a native ASP track from a Matroska file.

For AVC things are different.

thanks for the clarification, so, what you are saying in a nutshell is that XviD-in-AVI is a "well-established" hack supported by every tool and we don't have to worry about anything, right?

edit:
@stephanV: Personally I don't mind using x264.exe directly, the problem is not just AVI vs MP4, x264.exe is more powerful, and MeGUI is more convenient (for instance when you want to use the Main Profile)... I had already made up my mind that I wouldn't use x264VfW anymore. Still I was interested how I could convert AVC-in-AVI to AVC-in-MP4, partly out of curiosity, but I think this experience will help me a lot in some cases in the future.
Thanks a lot, anyway...

Isochroma · 29th August 2005, 22:50

When I mux xvid mp4 natively, media player classic 6.4.8.4 cannot recognize the stream anymore?

Mosu · 29th August 2005, 22:56

Quote:

Originally Posted by Liisachan

thanks for the clarification, so, what you are saying in a nutshell is that XviD-in-AVI is a "well-established" hack supported by every tool and we don't have to worry about anything, right?

That is 100% correct.

Mosu · 29th August 2005, 23:00

Quote:

Originally Posted by Isochroma

I created a native xvid mp4 from an xvid avi using mp4box. However, after I've muxed it into MKV using mkvmerge 1.5.0, the properties box shows the Codec ID as:

V_MS/VFW/FOURCC

Why is it being muxed as vfw and not natively?

I've given reasons a couple of posts ago. The quick version is:

a) compatibility (not all splitters/players support it),
b) until 1.5.5 it was very buggy (I've already fixed another bug that's still present in 1.5.5),
c) like Liisachan put it "it's a well-established hack that is supported by every tool out there". Again compatibility.
d) native ASP storage doesn't give a lot of pros compared to VfW mode storage at the moment.

#2 · 7th September 2005, 09:57

Hi guys every time I try to appened my end credits to the main film I get this error. In fact every time I try to append anything it fails.

mkvmerge 1.55
windows xp sp2
rmvb format tracks
useing Auto rv10 7.1 update to encode the rmvb streams

I'm sure this used to work in 1.40 or arround there :?

Mosu · 7th September 2005, 10:09

Any return code > 2 is a crash. Please upload the files somewhere, e.g. on my FTP server. Thanks.

Mosu · 7th September 2005, 18:10

Heya guys,

here we go! I consider this release to be a "major bugfix" release. There were a lot of issues that I was finally able to track down or that were simply new bugs I didn't know about before. So I strongly advise to upgrade to this version.

However, AVC aspect ratio info handling has been changed (see the ChangeLog below for details), and it's quite possible that new bugs have introduced in the process.

Here are the typical links...
...to the home page:
https://www.bunkus.org/videotools/mkvtoolnix/
...the source code:
https://www.bunkus.org/videotools/mk...-1.5.6.tar.bz2
...the Windows Unicode installer:
https://www.bunkus.org/videotools/mk....5.6-setup.exe

All the other packages are/will be available from the home page.

The ChangeLog since 1.5.5:
-----------------------------------------------------------------
2005-09-06 Moritz Bunkus <moritz@bunkus.org>
* mmg: bug fix: If the user selected an aspect ratio for a video track, then chose "File -> new", added a file, selected another video track and chose the same aspect ratio as before then it wasn't added to the command line. Fixes Anthill bugs 132 and 146.
* mkvmerge: bug fix: Support Qt/MP4 files with 64bit offset tables ('co64' atom instead of 'stco' atom).

2005-09-04 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: new feature: mkvmerge will remove the aspect ratio information from a AVC/h.264 video track bitstream and put it into the display dimensions (until now the AR information was kept on the bitstream level). The reason is that in Matroska the container AR is supposed to take precedence over bitstream AR, but some decoder programmers ignore the container AR in favour of bitstream AR.

2005-08-31 Moritz Bunkus <moritz@bunkus.org>
* mkvinfo: bug fix: The GUI couldn't open files with non-ASCII chars in the file name.

2005-08-30 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Display dimensions were reported for all tracks, even if they weren't present. In that case they allegedly were "0x0" which caused mmg to add "--display-dimensions ...:0x0" for each track read from a Matroska file, even if the tracks were not video tracks.

2005-08-28 Moritz Bunkus <moritz@bunkus.org>
* mkvextract: bug fix: The extracted timecodes were wrong for blocks with laced frames.

2005-08-25 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: If a Matroska file with a MPEG-4 part 2 video track was muxed into a Matroska file and the source file did not contain the display width/height elements for that track then the aspect ratio was extracted from the video data itself which clashes with the Matroska specs which say that display width/height default to the pixel width/height if they're not present.

2005-08-24 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: Native MPEG-4 ASP storage was still bugged: timecodes were assigned twice, frames referenced themselves.
* mkvmerge: bug fix: Embedded fonts and pictures in a SSA/ASS file are not discarded any longer. They are converted to Matroska attachments instead. Other sections that were discarded are added to the CodecPrivate data as are "Comment:" lines in the "[Events]" section. Those comment lines still lose their association for which "Dialogue:" line they were meant, but that cannot be changed.

2005-08-21 Moritz Bunkus <moritz@bunkus.org>
* mkvmerge: bug fix: --delay was not working at all.
* mkvmerge: bug fix: Single digit numbers followed by 's' were not recognized as valid numbers with a unit (e.g. in '--delay 0:9s').
-----------------------------------------------------------------

Have fun

Pirks · 8th September 2005, 06:18

Quote:

Originally Posted by Mosu

* mkvmerge: bug fix: Support Qt/MP4 files with 64bit offset tables ('co64' atom instead of 'stco' atom).
Have fun

Where is my portion of fun, Mosu? :-) I thought that 'co64' bug was mine but it was not. So where is my big fat ugly 'oops.mov' bug?

Liisachan · 8th September 2005, 22:38

Quote:

Other sections that were discarded are added
to the CodecPrivate data as are "Comment:" lines in the "[Events]"
section. Those comment lines still lose their association for
which "Dialogue:" line they were meant, but that cannot be
changed.

The Actor field is all empty in the demuxed ASS. Is this a known limitation, by desing, or a bug? If this can't be fixed, maybe we should include every single SSA/ASS muxed into MKV redundantly as attachments.

Mosu · 9th September 2005, 07:42

Quote:

Originally Posted by Liisachan

The Actor field is all empty in the demuxed ASS. Is this a known limitation, by desing, or a bug? If this can't be fixed, maybe we should include every single SSA/ASS muxed into MKV redundantly as attachments.

Quoting the Matroska codec specs for SSA/ASS:

Quote:

Events are stored in the Block in this order: ReadOrder, Layer, Style, Name, MarginL, MarginR, MarginV, Effect, Text (Layer comes from ASS specs ... it's empty for SSA.) "ReadOrder field is needed for the decoder to be able to reorder the streamed samples as they were placed originally in the file.

So yes, it is a limitation. You can of course attach the ssa/ass file in each case. It was never my intention that you could first mux and then demux ssa/ass into Matroska and out again without any losses because that is simply not possible (and not wanted either).

Mosu · 9th September 2005, 07:42

Quote:

Originally Posted by Pirks

Where is my portion of fun, Mosu? :-) I thought that 'co64' bug was mine but it was not. So where is my big fat ugly 'oops.mov' bug?

That one's still broken, yes

28th August 2005, 12:45	#141 \| Link
Liisachan 李姗倩 Lǐ Shān Qiàn Join Date: Nov 2002 Posts: 1,340	Extracting .h264 should work one way or another, but I have no luck so far. The bottom line is, I will use x264.exe, not VfW. Like Doom9 said, it's pointless to use AVI when transmuxing it into MKV. Anyway this doesn't work: Code: C:\test>avi2raw60 avc.avi avc.m4v avi2raw60 - mpeg4ip version 1.3.6 avi2raw60: warning: 3 zero length frames ignored 2214 video frames written It says 3 frames were dropped. I guess because I used 3 consecutive b-frames and apparently avi2raw60 doesn't know the hack used by x264vfw... And even if I ignore the 3 frames mp4box doesn't like the above output. Code: C:\test>mp4box -add avc.m4v -new avc.mp4 MPEG-4 Video import - 0 x 0 @ 25.0000 FPS Indicated Profile: Simple Profile @ Level 1 Import results: 0 VOPs (0 Is - 0 Ps) Converting to ISMA Audio-Video MP4 file... Adjusting visual track size to 0 x 0 Saving avc.mp4: 0.500 secs Interleaving C:\test>mkvmerge -o test.mkv avc.mp4 mkvmerge v1.5.5 ('Another White Dash') built on Aug 21 2005 15:40:13 'avc.mp4': Using the Quicktime/MP4 demultiplexer. Warning: Quicktime/MP4 reader: Track 201 is missing some data. Broken header atoms? Warning: 'avc.mp4': No tracks will be copied from this file. This usually indicates a mistake in the command line. Error: No streams to output were found. Aborting. I tried mp4creator too. mp4creator is a bit kind, saying "This is not recommended due to the use of b-frames" but in the end it says "mp4creator: video compressor x264 not recognized"... I asked VLC Player too to transmux my AVI to MP4, but the resulted file was broken. So my impression now is, almost nobody knows the hack used by x264vfw...perhaps the only exception is ffdshow.

28th August 2005, 13:59	#143 \| Link
Liisachan 李姗倩 Lǐ Shān Qiàn Join Date: Nov 2002 Posts: 1,340	Thanks for the tip, it worked now, after I renamed .m4v to .264 MP4 is 3 frames shorter, but the dropped are the last 3 frames (not the frist 3 frames nor random 3 frames) and lucily they happen to be the sequence of meaningless black frames. Oh, btw didn't you see this part? C:\test>avi2raw60 avc.avi avc.m4v avi2raw60 - mpeg4ip version 1.3.6 It's very new--even newer than the newest version on the page you mentioned (that is 1.3.5 as of writing). I know it was renamed, but celtic_druid's 1.3.6cvs has avi2raw"60" --edit I tried 1.3.5 too just in case, but the 3 frames will be dropped no matter what. They are unimportant frames in this case tho. I've also noticed that I need -fps switch unless the video is 25.0fps. so, for reference, the commandline I used is: avi2raw avc.avi raw.264 mp4box -fps 23.976 -add raw.264 avc.mp4 mkvmerge -o output.mkv avc.mp4 Last edited by Liisachan; 28th August 2005 at 14:17.

29th August 2005, 22:50	#151 \| Link
Isochroma Registered User Join Date: Mar 2005 Posts: 468	native mp4? When I mux xvid mp4 natively, media player classic 6.4.8.4 cannot recognize the stream anymore? Last edited by Isochroma; 29th August 2005 at 22:57.

7th September 2005, 09:57	#154 \| Link
#2 Registered User Join Date: Apr 2003 Posts: 114	mkvmerge FAILED with a return code of 3 Hi guys every time I try to appened my end credits to the main film I get this error. In fact every time I try to append anything it fails. mkvmerge 1.55 windows xp sp2 rmvb format tracks useing Auto rv10 7.1 update to encode the rmvb streams I'm sure this used to work in 1.40 or arround there :?

7th September 2005, 10:09	#155 \| Link
Mosu MKVToolNix author Join Date: Sep 2002 Location: Braunschweig, Germany Posts: 4,281	Any return code > 2 is a crash. Please upload the files somewhere, e.g. on my FTP server. Thanks. __________________ Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server.

28th August 2005, 15:09	#144 \| Link
stephanV gone Join Date: Apr 2004 Posts: 1,706	The three dropped frames are empty chunks at the beginning of the avi file needed for the b-frame encoding delay and you will lose the last three frames because effectively those frames are never received by your encoding app (again, due to the delay).

29th August 2005, 01:05	#145 \| Link
Liisachan 李姗倩 Lǐ Shān Qiàn Join Date: Nov 2002 Posts: 1,340	I've suddenly realized that maybe I should use MP4 too even when I'm encoding with XviD, if the final target format is MKV. I think mkvmerge will accept MPEG-4 Part2 Video in MP4 and at least Haali Splitter (and perhaps MPC) will play it too. I should test that later to see the upsides and downsides... @stephanV: I see. Thanks for info. But can't the encoder (x264) add 3 null frames at the end of the clip when it decides to put the 'empty chunks at the beginning of avi file'?

29th August 2005, 08:47	#147 \| Link
celtic_druid Registered User Join Date: Oct 2001 Location: Melbourne, Australia Posts: 2,171	Guess I usually rename avi2raw. I was in somewhat of a hurry Friday night when I compiled/released 1.3.6.

7th September 2005, 18:10	#156 \| Link
Mosu MKVToolNix author Join Date: Sep 2002 Location: Braunschweig, Germany Posts: 4,281	mkvtoolnix 1.5.6 has been released Heya guys, here we go! I consider this release to be a "major bugfix" release. There were a lot of issues that I was finally able to track down or that were simply new bugs I didn't know about before. So I strongly advise to upgrade to this version. However, AVC aspect ratio info handling has been changed (see the ChangeLog below for details), and it's quite possible that new bugs have introduced in the process. Here are the typical links... ...to the home page: https://www.bunkus.org/videotools/mkvtoolnix/ ...the source code: https://www.bunkus.org/videotools/mk...-1.5.6.tar.bz2 ...the Windows Unicode installer: https://www.bunkus.org/videotools/mk....5.6-setup.exe All the other packages are/will be available from the home page. The ChangeLog since 1.5.5: ----------------------------------------------------------------- 2005-09-06 Moritz Bunkus <moritz@bunkus.org> * mmg: bug fix: If the user selected an aspect ratio for a video track, then chose "File -> new", added a file, selected another video track and chose the same aspect ratio as before then it wasn't added to the command line. Fixes Anthill bugs 132 and 146. * mkvmerge: bug fix: Support Qt/MP4 files with 64bit offset tables ('co64' atom instead of 'stco' atom). 2005-09-04 Moritz Bunkus <moritz@bunkus.org> * mkvmerge: new feature: mkvmerge will remove the aspect ratio information from a AVC/h.264 video track bitstream and put it into the display dimensions (until now the AR information was kept on the bitstream level). The reason is that in Matroska the container AR is supposed to take precedence over bitstream AR, but some decoder programmers ignore the container AR in favour of bitstream AR. 2005-08-31 Moritz Bunkus <moritz@bunkus.org> * mkvinfo: bug fix: The GUI couldn't open files with non-ASCII chars in the file name. 2005-08-30 Moritz Bunkus <moritz@bunkus.org> * mkvmerge: bug fix: Display dimensions were reported for all tracks, even if they weren't present. In that case they allegedly were "0x0" which caused mmg to add "--display-dimensions ...:0x0" for each track read from a Matroska file, even if the tracks were not video tracks. 2005-08-28 Moritz Bunkus <moritz@bunkus.org> * mkvextract: bug fix: The extracted timecodes were wrong for blocks with laced frames. 2005-08-25 Moritz Bunkus <moritz@bunkus.org> * mkvmerge: bug fix: If a Matroska file with a MPEG-4 part 2 video track was muxed into a Matroska file and the source file did not contain the display width/height elements for that track then the aspect ratio was extracted from the video data itself which clashes with the Matroska specs which say that display width/height default to the pixel width/height if they're not present. 2005-08-24 Moritz Bunkus <moritz@bunkus.org> * mkvmerge: bug fix: Native MPEG-4 ASP storage was still bugged: timecodes were assigned twice, frames referenced themselves. * mkvmerge: bug fix: Embedded fonts and pictures in a SSA/ASS file are not discarded any longer. They are converted to Matroska attachments instead. Other sections that were discarded are added to the CodecPrivate data as are "Comment:" lines in the "[Events]" section. Those comment lines still lose their association for which "Dialogue:" line they were meant, but that cannot be changed. 2005-08-21 Moritz Bunkus <moritz@bunkus.org> * mkvmerge: bug fix: --delay was not working at all. * mkvmerge: bug fix: Single digit numbers followed by 's' were not recognized as valid numbers with a unit (e.g. in '--delay 0:9s'). ----------------------------------------------------------------- Have fun __________________ Latest MKVToolNix is v83.0 If I ever ask you to upload something, please use my file server.