[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.