Quote:
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:
Code:
[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.
Quote:
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...