mkvtoolnix 4.1.1 released

[Ritsuka]

Oh well, I did one too but forgot about it.
edit: now available on http://www.bunkus.org/videotools/mkv...ds.html#macosx

It contains the gui too and works on 10.4.
Hopefully Mosu could put it his site like the 2.0 I compiled some years ago.

[SeeMoreDigital]

Originally Posted by Mosu

Maybe, maybe not. Sample files, please?

Hi Mosu,

What I'm proposing is already possible. Currently however, in order to retain the "Video Stream Level Signalling" for MPEG-4 Part-2/Part-10 video streams, you have to go to the "User Defined Options" and write "--engage keep_bitstream_ar_info" in the box provided.

What I'm proposing is a "check-box" implementation. Something like this: -




Cheers

[Mosu]

Originally Posted by SeeMoreDigital

What I'm proposing is already possible. Currently however, in order to retain the "Video Stream Level Signalling" for MPEG-4 Part-2/Part-10 video streams, you have to go to the "User Defined Options" and write "--engage keep_bitstream_ar_info" in the box provided.

Ah, that's what you meant. Nope, sorry, I won't add an option for this. The reason is that in Matroska all information on every level should be the same. What I mean is: with AVC and other video formats there's the aspect ratio information on the bitstream level and the aspect ratio information on the container level. These two should always be the same -- otherwise how should a player decide which information to use? (The container information obivously, but it's ambiuous.)

The --engage option is there for users who know what they're doing, but I don't want to make it too easy for unexperienced users to shoot themselves in their feet.

[SeeMoreDigital]

Okay.... I understand what you mean. Keeping both CLS (Container Level Signalling) and SLS (Stream Level Signalling) would present confusion

Just a thought... Would it be possible to retain the Stream Level Signalling and not have any Container Level Signalling?

Personally, I've never really liked the idea of storing aspect ratio signalling at the container level

[Mosu]

Originally Posted by SeeMoreDigital

Just a thought... Would it be possible to retain the Stream Level Signalling and not have any Container Level Signalling?

Not with mkvmerge, no. And I won't add such an option, sorry.

[Mosu]

Originally Posted by ataraxia937

I have built a package of mkvtoolnix 2.3.0 for Leopard.

and

Originally Posted by Ritsuka

Oh well, I did one too but forgot about it.

Thanks a lot to the both of you. I'm hosting both of your pakages on my download page now.

[Mosu]

I've spent the last couple of days implementing support for VC-1 video tracks. mkvmerge can now read VC1 tracks from EVOBs and from VC1 elementary streams like the ones that EVODemux produces. mkvmerge can still not read ASF/WMV files. You should not attempt to read VC1 from AVIs yet as the timecodes will probably be wrong (will be taken care of this weekend).

What I haven't been able to test:

• Sample/pixel aspect ratio. The sample files that I have only have a 1:1 sample aspect ratio or no display information extension at all; therefore any other sample aspect ratio will cause mkvmerge to output a warning.
• Audio/video synchronization. Unfortunately I don't have a single sample with which I can properly test A/V sync.
• Timecodes for progressive material. The samples I have all seem to be interlaced.
• The samples I have all use frame units (start code 0x00 00 01 0d). None use field or slice units (start codes 0x00 00 01 0c and 0x00 00 01 0b respectively). mkvmerge will abort if it encounters those. I don't even know whether or not VC1 allows field or slice units at all or if this is just allowed in WMV9.

As you can see I definitely need more sample files So if you'd like to upload a couple to my FTP server I'd be very grateful. Especially ones that cause any problem with mkvmerge. Please only upload EVOBs and VC1 raw elementary streams; I cannot handle WMVs at the moment. The samples should be "big enough"; unfortunately this often means a size of 50 MB or more. My FTP server can take it though, so don't be shy.

Here's the Windows build with VC1 support: http://www.bunkus.org/videotools/mkv...20080919-1.rar

Oh, a short question. How do I play back EAC3 without a hardware decoder on Windows? I "only" have the current CCCP installed, and MPC stalls on files with EAC3 sound tracks. AC3 playback is working, of course, ffdshow takes care of that.

[madshi]

Originally Posted by Mosu

I've spent the last couple of days implementing support for VC-1 video tracks. mkvmerge can now read VC1 tracks from EVOBs and from VC1 elementary streams like the ones that EVODemux produces. mkvmerge can still not read ASF/WMV files. You should not attempt to read VC1 from AVIs yet as the timecodes will probably be wrong (will be taken care of this weekend).

What I haven't been able to test:

• Sample/pixel aspect ratio. The sample files that I have only have a 1:1 sample aspect ratio or no display information extension at all; therefore any other sample aspect ratio will cause mkvmerge to output a warning.
• Audio/video synchronization. Unfortunately I don't have a single sample with which I can properly test A/V sync.
• Timecodes for progressive material. The samples I have all seem to be interlaced.
• The samples I have all use frame units (start code 0x00 00 01 0d). None use field or slice units (start codes 0x00 00 01 0c and 0x00 00 01 0b respectively). mkvmerge will abort if it encounters those. I don't even know whether or not VC1 allows field or slice units at all or if this is just allowed in WMV9.

As you can see I definitely need more sample files So if you'd like to upload a couple to my FTP server I'd be very grateful. Especially ones that cause any problem with mkvmerge. Please only upload EVOBs and VC1 raw elementary streams; I cannot handle WMVs at the moment. The samples should be "big enough"; unfortunately this often means a size of 50 MB or more. My FTP server can take it though, so don't be shy.

Here's the Windows build with VC1 support: http://www.bunkus.org/videotools/mkv...20080919-1.rar

Thanks! A few hints:

(1) For aspect ratio use DISPLAY_HORIZ/VERT_SIZE in relation to MAX_CODED_WIDTH/HEIGHT. You should totally ignore the ASPECT_RATIO bitstream elements. Only this way aspect ratio works correctly.

(2) For best muxing each frame should consist of:

[00 00 01 0f [...]] [00 00 01 0e [...]] 00 00 01 0d [...] [00 00 01 0c [...]] [00 00 01 (1b-1f) [...]]

In other words: You must not strip the sequence headers. Furthermore each MKV frame should contain exactly one "00 00 01 0d" part. Each MKV frame should begin with either "00 00 01 0f" or "00 00 01 0e" or "00 00 01 0d".

(3) AFAIK there's no "temporal_reference" field in the VC-1 bitstream nor anything similar. So I think you should just increase timestamps constantly with each frame. Which is different to MPEG2 and h264 where timestamps can jump back and forth, depending on "temporal_reference" respectively "pic_order_cnt".

(4) I've never seen "00 00 01 0b" used yet in any HD DVD or Blu-Ray streams. But "00 00 01 0c" is rather common in interlaced HD DVD and Blu-Ray streams. When there's "00 00 01 0c", there's a "00 00 01 0d" first. You need to mux them both into one MKV frame. If you separate them, the MS VC-1 decoder will show artifacts.

(5) You can double check whether your muxes are correct by comparing your MKVs with those created by eac3to ("mkvinfo -v"). eac3to's VC-1 muxing has been tested with hundreds of HD DVDs and Blu-Rays and I'm not aware of any problems. For eac3to to successfully mux VC-1 you need the latest Haali Media Splitter to be installed (download link see "eac3to -test").

I'll upload a few samples.

Originally Posted by Mosu

Oh, a short question. How do I play back EAC3 without a hardware decoder on Windows? I "only" have the current CCCP installed, and MPC stalls on files with EAC3 sound tracks. AC3 playback is working, of course, ffdshow takes care of that.

The latest ffdshow tryouts version can decode E-AC3, as long as it's part of an EVO or m2ts container, I think. You need the very latest ffdshow, since this was added just a couple of days ago...

[Mosu]

Originally Posted by madshi

Thanks! A few hints:

(1) For aspect ratio use DISPLAY_HORIZ/VERT_SIZE in relation to MAX_CODED_WIDTH/HEIGHT. You should totally ignore the ASPECT_RATIO bitstream elements. Only this way aspect ratio works correctly.

At the moment I simply use DISPLAY_HORIZ/VERT_SIZE as the values for Matroska's "display width/display height" fields. Anyway, all samples I have have identical DISPLAY_HORIZ/VERT_SIZE and MAX_CODED_WIDTH/HEIGHT values, so I can't test that way either

(2) For best muxing each frame should consist of:

[00 00 01 0f [...]] [00 00 01 0e [...]] 00 00 01 0d [...] [00 00 01 0c [...]] [00 00 01 (1b-1f) [...]]

In other words: You must not strip the sequence headers. Furthermore each MKV frame should contain exactly one "00 00 01 0d" part. Each MKV frame should begin with either "00 00 01 0f" or "00 00 01 0e" or "00 00 01 0d".

Ah. At the moment I've implemented muxing in V_MS/VFW/FOURCC mode that Haali's Matroska muxer also writes (dunno which version of Haali's muxer I've installed; I did the muxing with graphedit: EVO as the source, Haali's muxer connected directly to the EVO's video output pin). This one is quite different, though. It strips all sequence headers and entrypoints from the frames and puts one instance of each into CodecPrivate behing the BITMAPINFOHEADER.

I don't like it all that much myself, but I didn't know that eac3to can mux VC1 into Matroska. I'll take a look at how eac3to muxes VC1 and adopt mkvmerge's output accordingly.

So the basic warning is: Don't use the current mkvmerge for anything you want to keep! The way it muxes WILL change!

(3) AFAIK there's no "temporal_reference" field in the VC-1 bitstream nor anything similar. So I think you should just increase timestamps constantly with each frame. Which is different to MPEG2 and h264 where timestamps can jump back and forth, depending on "temporal_reference" respectively "pic_order_cnt".

True, but depending on the FRMCNT and RFF fields/flags in the frames (in combination with the sequence header's INTERLACE flag) the frame's duration may be longer than 1/FPS. That's what Haali's muxer did, anyay...

(4) I've never seen "00 00 01 0b" used yet in any HD DVD or Blu-Ray streams.

That's goot

But "00 00 01 0c" is rather common in interlaced HD DVD and Blu-Ray streams. When there's "00 00 01 0c", there's a "00 00 01 0d" first. You need to mux them both into one MKV frame. If you separate them, the MS VC-1 decoder will show artifacts.

Ok. That should not be such a big problem.

(5) You can double check whether your muxes are correct by comparing your MKVs with those created by eac3to ("mkvinfo -v"). eac3to's VC-1 muxing has been tested with hundreds of HD DVDs and Blu-Rays and I'm not aware of any problems. For eac3to to successfully mux VC-1 you need the latest Haali Media Splitter to be installed (download link see "eac3to -test").

Will do.

I'll upload a few samples.

Thanks a lot, both for the files and the info.

The latest ffdshow tryouts version can decode E-AC3, as long as it's part of an EVO or m2ts container, I think. You need the very latest ffdshow, since this was added just a couple of days ago...

Ah, good to know. I'll install it.

[madshi]

Originally Posted by Mosu

At the moment I simply use DISPLAY_HORIZ/VERT_SIZE as the values for Matroska's "display width/display height" fields.

That's exactly the right way. I'm already uploading 2 files with funny aspect ratios.

Originally Posted by Mosu

Ah. At the moment I've implemented muxing in V_MS/VFW/FOURCC mode that Haali's Matroska muxer also writes (dunno which version of Haali's muxer I've installed; I did the muxing with graphedit: EVO as the source, Haali's muxer connected directly to the EVO's video output pin). This one is quite different, though. It strips all sequence headers and entrypoints from the frames and puts one instance of each into CodecPrivate behing the BITMAPINFOHEADER.

Earlier versions of Haali's muxer did behave that way. But that resulted in artifacts with some HD DVD movies cause in some HD DVD movies the sequence headers change in the middle of the movie. I've reported that to Haali and he changed his way of VC-1 muxing in newer versions of his muxer to the same way eac3to is using. I guess you have an old Haali version installed on your PC.

Originally Posted by Mosu

True, but depending on the FRMCNT and RFF fields/flags in the frames (in combination with the sequence header's INTERLACE flag) the frame's duration may be longer than 1/FPS. That's what Haali's muxer did, anyay...

That's correct.

[nautilus7]

Originally Posted by Mosu

Ah, good to know. I'll install it.

ffdshow builds on sourceforge don't support E-AC3, so install this build posted by albain here. It's his last test build.

You can also play raw E-AC3 streams.

[Mosu]

Alrighty, thanks for your tips and the files that you guys have uploaded. Here's a new build that implements proper VC1 muxing:

http://www.bunkus.org/videotools/mkv...20080920-1.rar

Have fun testing

[STaRGaZeR]

VC1 tracks will be muxed in V_MS/VFW/FOURCC mode right Mosu?

[Mosu]

Yes, the same way they're muxed by Haali's muxer / by eac3to. You need a current version of Haali's splitter from http://haali.net/mkv/

[STaRGaZeR]

Nice. I can remember reading something about Haali's muxer using V_VC1, but it was removed later on because of some incompatibility with Microsoft's WMVideo Decoder DMO, IIRC. So I assume V_MS/VFW/FOURCC is the correct mode for the VC-1 codec family.

Will you add Windows Media Audio formats support in the future?

[Mosu]

Maybe, maybe not. They're pretty low on my TODO list.

[NanoBot]

Hi,

thanks for the support of raw VC.1 tracks, but it looks like you have forgotten to include the never versions of some dlls in the update archiv ?

"Die Anwendung kann nicht gestartet werden, weil wxbase28u_gcc_custom.dll nicht gefunden wurde"

C.U. NanoBot

[Eragon4ever]

Install 2.3.0 and unpack the archive on top of it. The dlls are in the installer.

[Mosu]

Eragon's correct. This is a newer build of v2.3.0 which includes the newer wxWidgets version.

[NanoBot]

Hi,

thanks for the fast answer. I accidentially extracted the archiv to an existing 2.2 installation or an older of 2.3 installation, and of course this could not work

I reinstalled from the actual 2.3 installer and extracted the archiv, and now everything works fine. I am going to test the VC1 import function

C.U. NanoBot