EVOB De/Multiplexers

[KhasMek]

Here's a stand-alone command line EVOB demuxer for folks to try:

http://www.w6rz.net/evob_demux.zip

Usage is:

demux <-p> <infile> <video outfile> <audio outfile> <audio track>

typically:

demux movie.evo bits.mpv bits.mpa 0

The -p option dumps the PES header PTS values.

Unfortunately, I have only one .evo sample file that bond pointed me to. So it's not very well tested. However, if folks could PM me with samples (of all flavors, VC-1, H.264, DD, DD+, etc.), it should be fairly easy to add stream types.

Ron

worked great on the video for me, but nothing from the audio tracks (i have tried 0-3)

cheers on the great work so far btw....

[madshi]

The MPEG Tools of TMpgEnc seem to be able to extract all streams just fine. Stream ID "0xBF" seems to be Dolby Digital Plus and stream ID "0xFD" seems to be VC-1.

[Isochroma]

@asasadad_1: The download link for your sample EVOB seems to be nonfunctional: the hoster's link doesn't work.

Could you upload the file to another hoster? There's lots of them - I use MegaUpload.

[_xxl]

Sample files:
ftp://mplayerhq.hu/MPlayer/samples/evob/

[Isochroma]

@madshi: TMpgEnc tool extracts the H.264 in my EVOB ok, but the audio stream, once extracted, shows up in mkvmerge as video. When muxed, it plays a few seconds of audio in MPC then locks.

[madshi]

@madshi: TMpgEnc tool extracts the H.264 in my EVOB ok, but the audio stream, once extracted, shows up in mkvmerge as video. When muxed, it plays a few seconds of audio in MPC then locks.
What audio format is that? DD+? The question is: Who is responsible for the MPC lock? Is it the AC3 decoder? Or did muxing do something wrong? Or did TMpgEnc demux incorrectly? Maybe muxing DD+ must use a different stream indicator than DD? I've no idea...

[Isochroma]

Using the BLACK.EVO file...

First, using the Sonic HD demuxer and Sonic A/V filters, the file seems to play OK in MPC, but of course the screen is black. Seeking works. The audio stream shows up as Dolby Stereo.

TMPGENC's tool demuxes the video 'correctly', producing the exact same size file as using graphedit, Elecard MPEG Demultiplexer, and DVB dump filter.

However, this .vc1 file will only play in MPC using the Sonic decoder; if it is disabled and we hope that the WMT Advanced Profile decoder works, it doesn't - MPC report a pin failing to render.

MKVMerge won't mux it "file identification error", but using Haali's MKV muxer in Graphedit, it works...

The MKV file plays in MPC using Sonic's decoder, but plays as fast as it can decode (MPC's Properties report no framerate).

Disabling the Sonic decoder and using the WMT decoder, the file opens but won't play. Properties again shows 1920x1080 WVC1 but no framerate.

It is clear that the WVC1 extracted is a raw stream, which is missing framerate and keyframe data, and thus requires muxing to make it work properly.

The DVBPortal WMV Muxer/Encoder won't touch it, reports this:

"BLACK-0xFD.vc1 rejected due to no video or unknown codec"

Now for the audio:

Using TMPGEnc's MPEG Tools, the audio (private_stream_1 (0xC0) is extracted. However, the file fails to render in MPC unless BOTH the Sonic HD Demuxer and the Sonic audio decoder are enabled. Even then, it hangs on frame 0 and uses 100% CPU.

[madshi]

Just found out that by "prefer"ing Cyberlink's MPEG Splitter and Cyberlink's Demultiplexer, MPC seems to "understand" the EVO correctly. It tries to play the VC1 stream directly from the EVO file. Unfortunately I don't have the Sonic filters, so I can't check whether there's actually a valid picture. The Cyberlink VC-1 decoder complains about not being able to connect the output pin.

[honai]

Since you can't render the demuxed streams there's no indication that Cyberlink's demuxer actually produce any meaningful streams. It may just be garbage.

[mikeathome]

Hi,

good old VStrip + Gui is able to demux something. It's nice because you can do a short start and then stop which will list you found streams easy enough. These can than be used for the stripping setup in output tab.

BUT can't do anything with these. Something's really wrong here, looks like the audiostream is still encrypted, no way to play back with anything. KK e.g. has it audio streams in
0xbd 0xc0
0xbd 0xc2
0xbd 0xc1
0xbd 0xc8

Video 0xfd

Subs
0xbd 0x22
0xbd 0x21
0xbd 0x20

Video demux does not work.

The real shit is that Intervideos iviaudio does not produces anything but 2 ch stereo since it is the only one which demux from EVO. Btw. any idea how to save this as an wav?

mike

[drmpeg]

I've updated my demuxer to fix the audio problems. You now have to select the audio format (DD, DD+, etc.).

http://www.w6rz.net/evob_demux.zip

EVOB Demuxer = Version 0.1

Usage:

demux <-p> <infile> <video outfile> <audio outfile> <audio format> <audio track>

Typically:

demux movie.evo bits.mpv bits.mpa 1 0

Audio formats:

0 = DD
1 = DD+
2 = DTS-HD
3 = LPCM
4 = MLP

Ron

[drmpeg]

It is clear that the WVC1 extracted is a raw stream, which is missing framerate and keyframe data, and thus requires muxing to make it work properly.


I can decode the raw VC-1 streams. All the required information is present.

Here's a dump of the sequence header for asasadad_1's stream:

SeqHeader: 1
+->Offset: 0
+->Size: 22
+->PROFILE: 3 (Advanced)
+->LEVEL: 3 (AP@L3)
+->COLORDIFF_FORMAT: 1 (4:2:0)
+->FRMRTQ_POSTPROC: 7 (30 frm/s)
+->BITRTQ_POSTPROC: 31 (2016 kbps)
+->POSTPROCFLAG: 0 (FALSE)
+->MAX_CODED_WIDTH: 959 (1920)
+->MAX_CODED_HEIGHT: 539 (1080)
+->PULLDOWN: 1 (TRUE)
+->INTERLACE: 1 (TRUE)
+->TFCNTRFLAG: 0 (FALSE)
+->FINTERPFLAG: 0 (FALSE)
+->RESERVED: 1 (TRUE)
+->PSF: 0 (FALSE)
+->DISPLAY_EXT: 1 (TRUE)
+->DISP_HORIZ_SIZE: 1919 (1920)
+->DISP_VERT_SIZE: 1079 (1080)
+->ASPECT_RATIO_FLAG: 1 (TRUE)
+->ASPECT_RATIO: 1 (1:1)
+->FRAMERATE_FLAG: 1 (TRUE)
+->FRAMERATEIND: 0 (FALSE)
+->FRAMERATENR: 3 (30*1000)
+->FRAMERATEDR: 2 (1001)
+->COLOR_FORMAT_FLAG: 0 (FALSE)
+->HRD_PARAM_FLAG: 1 (TRUE)
+->HRD_PARAM
| +->HRD_NUM_LEAKY_BUCKETS: 1
| +->BIT_RATE_EXPONENT: 3 (9)
| +->BUFFER_SIZE_EXPONENT: 4 (8)
| +->HRD_RATE: 46874
| +->HRD_BUFFER: 57599

Ron

[orbitlee]

@drmpeg, thanks a lot for your evob_demux tool. The output is 100% match with my result, for both video and audio. My process is more troublesome, though. I use graphedit to demux the VC1 video and DTS/DD+ audio. For DD+ audio, since intervideo demux outputs MPEG2_PES, I had to write another tool to strip the PES packet header and leading 4 bytes(timestamp?).

For the demuxed VC1 raw stream and DTS/DD+ audio, I'm pretty sure they are legitimate. VC1 video stream can be analyzed with elecard stream analyzer(drmpeg, which tool you are using to dump VC1?), can be imported into sonic scenarist, can be played in graphedit(with elecard demultiplexer and Sonic video decoder). DTS/DD+ audio stream also can be imported into sonic scenarist.

A feature request, is it possible to show how many audio tracks(and their format) in EVO, or, at least, a wildcard audio format can be used for <audio format> parameter?

[_xxl]

demux.exe mainintro.evo bits.mpv bits.mpa 1 0
I can't play bits.mpv.

[kurt]

demux.exe mainintro.evo bits.mpv bits.mpa 1 0
I can't play bits.mpv.
I tried to demux delscene1.evo from your ftp and it worked great with demux.exe delscene1.evo bits.mpv bits.mpa 1 0

Muxed the ouptut in mkvtoolnix together and it plays fine with Intervideo Video Decoder (ffdshow produces interlaced artifacts, same as gabest mpeg2 decoder) and AC3filter. Trying to deinterlace in ffdshow doesn't help so far.

But that delscene1.evo doesn't contain a vc-1 stream, does it?
Do you have a mirror for black.evo?

Edit: TomSMocomp deinterlacer did the trick in ffdshow :)
Edit2: nevermind, I could download black.evo with leechftp in the meantime

[holzi]

the delscene1.evo contains a MPEG2 Video Stream.

[vsv]

If evob preserve a few audio streams and subtitles?
What syntax for demux? Thanks.

[SeeMoreDigital]

the delscene1.evo contains a MPEG2 Video Stream.DGIndex seems to have no problems de-muxing the MPEG-2 video streams out of .EVO files.... Sadly, it's unable to detect and de-mux the audio streams though...

[orbitlee]

Hi,
PLEASE, a step by step howto get a DD+ into Scenarist. I am trying this badly now since days!

mike

check PM since this is off-topic.

[DeathMonk]

Has anyone tried to mux the HDDVD content after demux in scenarist?

It plays all jittery... And whats really wierd, even content that I encoded myself into AVC (from a panasonic 720p varicam) and authored in scenarist does the same thing.

[SeeMoreDigital]

I'm struggling....

By any chance, could somebody de-mux the audio stream from drevil_xxl's DELSCENE1.EVO sample and post a link to it please?


Many thanks

[Isochroma]

After demuxing a VC-1 track, I can only get it to play using Sonic's filter - even though I have the wvc1dmo installed.

This occurs using both the Elecard MPEG Demultiplexer and the Sonic HD Demux.

The Sonic gives me this error in MPC:

Media Type 0:
--------------------------
Video: WVC1 1920x1080 29.97fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {31435657-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 0
bTemporalCompression: 1
lSampleSize: 0
cbFormat: 146

And the Elecard gives me almost the same:

Media Type 0:
--------------------------
Video: WVC1 1920x1080 29.97fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {31435657-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 65535
cbFormat: 146

The only differences are bFixedSizeSamples and lSampleSize.

And finally, the most annoying thing is that the MS WVC1 DMO is fully registered and handles the exact Major and MinorTypes that MPC/Graphedit says it can't connect:

http://isochroma.com/Testfiles/Misc/doom9/vc1-dmo-1.gif

http://isochroma.com/Testfiles/Misc/doom9/vc1-dmo-2.gif

MajorType: 73646976-0000-0010-8000-00AA00389B71 [Video]
MinorType: 31435657-0000-0010-8000-00AA00389B71 [WVC1]

[kurt]

I'm struggling....

By any chance, could somebody de-mux the audio stream from drevil_xxl's DELSCENE1.EVO sample and post a link to it please?


Many thanks
here you are: http://home.arcor.de/kurdt/divers/delscene.mpa

with this commandline: demux delscene1.evo delscene.mpv delscene.mpa 1 0

[Isochroma]

Ok, I just figured it out!

Here is the Sonic Cinemaster decoder filter's MediaTypes:

http://isochroma.com/Testfiles/Misc/doom9/sonic-vdec-1.gif

Note that the WVC1's Minor Mediatype is not present in either two of the "Video" Designation types! Indeed, in order to accept VC1 streams, the Designation is listed as WVC1.

So the MS VC1 filter will work, but the VC1 must be inside a container whose splitter reports its Designation as Video.

Playing a raw VC1 stream directly, it is reported as type "WVC1", rather than type "Video", fourcc "WVC1"!

By muxing the VC1 stream into an MKV using Haali's muxer, the stream now 'plays' in MPC, using the MS VC1 decoder. However, it doesn't actually play properly because the framerate hasn't been set (it shows as 0), and sadly mkvmergegui won't let us set framerate on this type of stream.

http://isochroma.com/Testfiles/Misc/doom9/vc1-graph-1.png

[SeeMoreDigital]

here you are: http://home.arcor.de/kurdt/divers/delscene.mpa

with this commandline: demux delscene1.evo delscene.mpv delscene.mpa 1 0
Many thanks...

I'm curious though. How come the file carries a .MPA when it's an AC3 stream?


Cheers

[honai]

Uhm .. because you told the demuxer to write that extension?

[holzi]

well lets wait for a update for mkvmerge. :)
Because the headers according to:
http://forum.doom9.org/showpost.php?p=939290&postcount=112

are pressent.

BTW how did you muxx the VC-1 with graph-edit and hali muxxer?
I have never done that

[honai]

Doesn't DVBportal HDTV Reference Dump add timestamps?

[frogman]

Hi .. First post here.
I backup my KingKong movie. And following along I tried my hand in demux just a small sample file. Delogo.evo.
M:\movies\kingkong]demux delogo.evo bits.mpv bits.mpa 1 0

The demuxing went fine, byte count is good.
The bits.mpv play back in powerdvd hddvd but I can't find any apps out there that support playback of "bits.mpa".

Question is what multimedia applications playback ".mpa" !

[holzi]

it dosn't matter how you call that file.
It's important whats in it. And it is DD+ for witch there is no filter yet.

[SeeMoreDigital]

The demuxing went fine, byte count is good.
The bits.mpv play back in powerdvd hddvd but I can't find any apps out there that support playback of "bits.mpa".

Question is what multimedia applications playback ".mpa" !Hi and welcome to the forum...

Did you see my previous post?

[honai]

@Isochroma

Great work! Which files did you test this on? Commercial HD-DVD? I have a couple of them here as backups, containing VC-1 video streams, so I'll try your method later.

[holzi]

take a look @ http://forum.doom9.org/showpost.php?p=939034&postcount=104
for more samples the mainintro.evo is VC-1 too.

I'm still not able to muxx the VC-1 raw stream with hali muxxer :)
Pls give me a short how to ;)

[Isochroma]

Note: If you have an H264 (AVC) EVOB, see my Tutorial: Perfect AVC EVOB to MKV Remuxing (http://forum.doom9.org/showthread.php?p=935396#post935396)
for how to transmux to MKV. Decode is a snap after that.

To recap from my previous posts, here is the path for processing VC-1 video from an EVOB:

0. Obtain an EVOB (.EVO file) containing a VC-1 encoded video stream.
Samples for testing: UNILOGO.EVO (http://rapidshare.com/files/12467866/UNILOGO.EVO) (78 MB), wvc1.dd plus.evo (http://www.rogepost.com/n/7492649086) (15 MB)

1. Demux the VC-1 track using the latest demux.exe (http://www.w6rz.net/evob_demux.zip) posted by drmpeg, name it with a .vc1 extension.

2. Using GraphEdit, mux the VC-1 stream into an MKV using the Haali Matroska Muxer (contained in the
Haali Media Splitter (http://haali.cs.msu.ru/mkv/MatroskaSplitter.exe)). You must also have the Elecard MPEG Demultiplexer (part of the
Elecard MPEG-2 Decoder and Streaming Pack (http://www.elecard.com/products/product.php?product_id=149)).

Special Note on the Elecard Demuxer: The version included in the older 3.0 release will crash when connected
to a VC-1 EVO. The bad version is 1.0.19, the working version is 1.0.47 build 60321 (or later). See this post (http://forum.doom9.org/showthread.php?p=941246#post941246)
for more details; contact me by Private Message (http://forum.doom9.org/private.php?do=newpm&u=73458) if you have this problem.

Here is the graph:

http://isochroma.com/Testfiles/Misc/doom9/vc-1-mux-1.png

Note that the Elecard Demuxer's Ouput Pin is labelled 'VC-1'. This means the demuxer understands the format;
right now it is the only one, besides the Sonic, that does. It also 'understands' H264. Thus it can correctly deliver
elementary streams in either of these two formats, as well as good old fashioned MPEG-1/2, which covers all video
formats available in the HD-DVD and Blu-Ray specifications.

3. The resulting MKV file will not be properly valid;
checking its properties (install the Matroska Pack (http://packs.matroska.org/1.1.2/Matroska_Pack_Full.exe) to get this shell extension) we see:

http://isochroma.com/Testfiles/Misc/doom9/mkv-h-prop-1.png

Note the framerate of 0.000000 fps.

4. Create a file named time.txt (name doesn't matter but it should end in .txt), and into the file put these lines:

# timecode format v1
assume 24.000

5. Now run the latest MKVMerge GUI (http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-2.0.0-setup.exe)
(be sure to update it by copying the new files from the latest update package (http://www.bunkus.org/videotools/mkvtoolnix/win32/pre/mkvtoolnix-unicode-2.0.0-build20070117-1.rar))

Drop the .mkv file produced by Haali's muxer in MKVMergeGUI, then click on the video track.
In the Timecodes field, click the Browse button and select the .txt file made in step 4.
Finally, give the output filename some new name and click Start Muxing:

http://isochroma.com/Testfiles/Misc/doom9/vc-1-mux-2.png

6. Checking the Properties on this new MKV file shows us, to great delight and surely also
wonderment, that it has a real framerate with normal timecodes:

http://isochroma.com/Testfiles/Misc/doom9/mkv-prop-1.png

7. Now we can use MKVExtract GUI (http://download.videohelp.com/download/MKVExtractGUI-1.6.4.zip) to extract the VC-1 track to AVI:

http://isochroma.com/Testfiles/Misc/doom9/mkvextract-1.png

8. We can see that this AVI, though not openable with VCM-based software
(no VC-1 VCM codec exists right now), looks normal in Avicodec (http://avicodec.duby.info/ftp/AVIcodec_1.2_b110.exe):

http://isochroma.com/Testfiles/Misc/doom9/vc1-avi-1.png

9. For some unknown reason, the file won't play using the Microsoft VC-1 DirectShow filter,
but works just fine using the Sonic Cinemaster VideoDecoder 4.1.

Gabest's splitter won't work at all on this AVI, BUT both the Haali Media Splitter and System AVI splitter do!
So if you disable Gabest's internal in MPC, you can get playback just fine.

In my case, GraphEdit uses the System AVI splitter, but you should also be able to use the Haali Media Splitter:

http://isochroma.com/Testfiles/Misc/doom9/vc1-avi-graph.png

10. Now for the final, and might I say most delicious step: make an .avs file in the same folder as the AVI,
and into it put these lines:

directshowsource("wvc1.ddp.avi",fps=24)
trim(0,200)

You might ask, why the trim? And why fps=24? To answer these questions in reverse order:

1. It turns out this file's correct framerate is 24fps, determined by playing the .evo directly in MPC
and observing its playback length. And it also turns out that due to some oddness, the fps value
of the .avi, though it appears to be 24.0, will actually be 29.970 when opened via .avs.

2. For some reason the number of frames in the AVI exceeds the true number of frames by (29.970 / n),
where n is the real framerate. The original in this example has a framerate of 24fps, and there are
243 frames in the avi, so only the range 0-200 is valid (good idea to step thru to make sure,
theoretically it should be 195). The extra frames are (thankfully) all at the end in a contiguous
chunk, so it is easy to trim() them off.

Opening the AVI with VirtualDub (http://sourceforge.net/project/showfiles.php?group_id=9649&package_id=9727) (I use 1.5.10), we are pleased to observe:

http://isochroma.com/Testfiles/Misc/doom9/vc1-avi-vdub.png

The end result of this process is two files: an AVI and an AVS. The AVS file, when opened in VirtualDub, has these properties:

1. If the source is film, the served stream is always progressive, not requiring any IVTC, deinterlace, or decimation (duplicate removal)
2. Frame Size: Original Frame Size
3. Framerate: user calculated rate, should be accurate
4. Number of Frames: user calculated and trimmed()
5. Is seekable (all timestamps present), and decodes every frame within the valid range without error.

[honai]

Hmm. But isn't much of the process superfluous? If your goal is to play the file via DirectShowSource() why don't you just feed the EVO into the Sonic HD Demuxer (as you have the Sonic Video Decoder you also have the Demuxer) and then to the Video Decoder?

I think the target should be playback from an MKV/AVI container using Microsoft's VC-1 DMO. That way you also won't need the IVTC because telecine is only introduced by Sonic's Decoder. The source itself contains pure 24fps progressive, and Microsoft's decoder can output it as such.

EDIT:

According to another forum InterVideo's VC-1 Decoder also doesn't telecide the video but outputs pure 24fps.

[Isochroma]

@honai: after analyzing the frames, I've found that each one is unique, which means Sonic's filter is outputting pure progressive too! So the right thing to do is to create that timecode file (step 4) and set it to 23.976 or 24.

There are several problems with doing directshowsource() on the .evo:

1. Using directshowsource("filename.evo") fails:

http://isochroma.com/Testfiles/Misc/doom9/dss-fails-1.png

We next build a test graph to find out why it is failing:

http://isochroma.com/Testfiles/Misc/doom9/evo-graph-sysdemux.png

Aha! The System MPEG Demux is putting itself in there because it has higher merit, and not providing an output pin.
So let's make the graph manually, using the Sonic HD Demuxer this time:

http://isochroma.com/Testfiles/Misc/doom9/evo-graph-sonicdemux-1.png

Plays just fine in graphedit, but let's save the graph and try directshowsource("graph.GRF"):

http://isochroma.com/Testfiles/Misc/doom9/evo-graph-error-1.png

Ah! We must remember that AviSynth needs one (and only one!) video or audio pin in the graph open, so that it can connect.

Looking back at the graph, we see a number of open pins, and the video we want is blocked by the greedy Video Renderer. Let's enumerate the pins, and what we have to do to them to make this work:

1. Audio Out: must be closed
2. ~SPU Out: must be closed
3. ~CC Out: must be closed
4. Video Out: must be opened

We'll connect all those unconnected pins to the magic Null Renderer, which is very promiscuous (it connects to anything), and sends any samples straightaway to Hell, and then we'll delete the Video Renderer and then we'll have it working, right?

http://isochroma.com/Testfiles/Misc/doom9/evo-graph-error-2.png

Oh darn! Seems that nasty ~SPU pin won't connect to anything... and believe me, I've tried everything. Game over or restart?

[Xplode]

@honai: after analyzing the frames, I've found that each one is unique, which means Sonic's filter is outputting pure progressive too! So the right thing to do is to create that timecode file (step 4) and set it to 23.976 or 24.

There are several problems with doing directshowsource() on the .evo:

1. Using directshowsource("filename.evo") fails:

http://isochroma.com/Testfiles/Misc/doom9/dss-fails-1.png

We next build a test graph to find out why it is failing:

http://isochroma.com/Testfiles/Misc/doom9/evo-graph-sysdemux.png

Aha! The System MPEG Demux is putting itself in there because it has higher merit, and not providing an output pin.
So let's make the graph manually, using the Sonic HD Demuxer this time:

http://isochroma.com/Testfiles/Misc/doom9/evo-graph-sonicdemux-1.png

Plays just fine in graphedit, but let's save the graph and try directshowsource("graph.GRF"):

http://isochroma.com/Testfiles/Misc/doom9/evo-graph-error-1.png

Ah! We must remember that AviSynth needs one (and only one!) video or audio pin in the graph open, so that it can connect.

Looking back at the graph, we see a number of open pins, and the video we want is blocked by the greedy Video Renderer. Let's enumerate the pins, and what we have to do to them to make this work:

1. Audio Out: must be closed
2. ~SPU Out: must be closed
3. ~CC Out: must be closed
4. Video Out: must be opened

We'll connect all those unconnected pins to the magic Null Renderer, which is very promiscuous (it connects to anything), and sends any samples straightaway to Hell, and then we'll delete the Video Renderer and then we'll have it working, right?

http://isochroma.com/Testfiles/Misc/doom9/evo-graph-error-2.png

Oh darn! Seems that nasty ~SPU pin won't connect to anything... and believe me, I've tried everything. Game over or restart?

You don't need to use the null renderer on open pins to make it work in avisynth

[honai]

Well, my bet is on trying a different video renderer than Sonic's. That wasn't meant for standalone playback, anyway, but rather for internal use in their mastering solution.

The most promising path so far seems to be waiting for one of the devs to write a VC1->WMV/AVI muxer. crypto or Dmitry (SolveigMM) are working on this already.

[Isochroma]

@Xplode: AviSynth requires one and only one open pin to connect to a filter graph. I chose the null renderers because they're the most efficient way to dispose of pins.

If there was more than one open pin in the graph, how is AviSynth supposed to know where to connect? Read the error message carefully: "Only 1 stream supported for .GRF files..."

@honai: First, Sonic doesn't make a video renderer, they make a demuxer and two decoders.

Second, waiting for someone to write a VC-1 muxer could test your patience. I for one, will not wait - it could take months or years, maybe never... the method outlined above will get you an .avs that works, right now.

Until the much-anticipated bridge software arrives, let's try the proposed method, and maybe even think up some new ones and test them as well. That way we can continue to make progress, while others work on programming splitters/demuxers/muxers.

I will be testing further .evo files to verify that it works on all of them (encouraging others to do the same), and will report back shortly.

[honai]

Yep, I did mean video decoder and have used that term before.

I for one, will not wait - it could take months or years, maybe never...

Dmitry said it would take him a week, so ...

[Xplode]

@Xplode: AviSynth requires one and only one open pin to connect to a filter graph. I chose the null renderers because they're the most efficient way to dispose of pins.

If there was more than one open pin in the graph, how is AviSynth supposed to know where to connect? Read the error message carefully: "Only 1 stream supported for .GRF files..."



Avisynth opens the .GRF file without problems here without connecting ~SPU Out and ~CC Out to null renderer or some other renderer.
Do you use "audio=false" in your avisynth script?

[Isochroma]

@Xplode: Thanks for the idea! I didn't know about audio=false.

Nonetheless, using this on the .evo, vdub opens the avs and shows frame 0, but selecting File->Information, the number of keyframes increases continuously, and furthermore, seeking or even stepping to frame 1 doesn't work.

In other news, I've now tested my method against the second VC-1 EVOB (UNILOGO.EVO (http://rapidshare.com/files/12467866/UNILOGO.EVO)) (seems the originating post was removed) and found that it works perfectly.

My previous guide (Tutorial: Perfect VC-1 EVOB to .AVS Conversion (http://forum.doom9.org/showthread.php?p=939698#post939698)) has been updated to reflect various changes in methodology, mostly cleanup. I hope it becomes a useful reference for others.

I will also continue testing any .evo sample files posted to verify the accuracy and reliability of the method, so keep 'em coming!

[crypto]

@Isochroma
Great job. You are nearly there. When you have a playable VC-1 AVI, did you try to mux it into WMV using the dvbportal wmvmuxer or solveig asfwriter?

[honai]

When you have a playable VC-1 AVI, did you try to mux it into WMV using the dvbportal wmvmuxer?

Tried it with a sample:

File ...\out2_Track1.avi rejected due to no audio or unknown codec

EDIT:

Stuffed in some AC3 audio data, now the .AVI is correctly parsed and identified (correct framerate, no. of frames, resolution, etc), but conversion stalls at 99%, and only 66K are written to disk.

[crypto]

honai, Don't get confused by the error/warning you got first. It means, there is no audio in the avi, which is correct. Just use the video direct stream copy setting, an advanced [WVC1] 1920 x 1080 profile and save to wmv. Sorry for the confusing GUI, there is still work to do.

[honai]

Thanks for that hint, yes, that did it.

Now I got the same test file as an AVI and WMV, but ... it doesn't render properly when the WMV9 Advanced Profile Decoder is used. All I get is seemingly random colored blocks all over the place.

Here's the filter info from MPC:

- Connected to:

CLSID: {187463A0-5BB7-11D3-ACBE-0080C75E246E}
Filter: F:\_ Incoming\Pitch Black\HVDVD_TS\test.wmv
Pin: Raw Video 0

- Connection media type:

Video: WVC1 1920x1080 23.97fps 12583Kbps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {31435657-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 0
bTemporalCompression: 1
lSampleSize: 0
cbFormat: 134

VIDEOINFOHEADER:
rcSource: (0,0)-(1920,1080)
rcTarget: (0,0)-(1920,1080)
dwBitRate: 12583214
dwBitErrorRate: 0
AvgTimePerFrame: 417188

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 1920
dwPictAspectRatioY: 1080
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

BITMAPINFOHEADER:
biSize: 62
biWidth: 1920
biHeight: 1080
biPlanes: 1
biBitCount: 24
biCompression: WVC1
biSizeImage: 65536
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

pbFormat:
0000: 00 00 00 00 00 00 00 00 80 07 00 00 38 04 00 00 ........€...8...
0010: 00 00 00 00 00 00 00 00 80 07 00 00 38 04 00 00 ........€...8...
0020: 2e 01 c0 00 00 00 00 00 a4 5d 06 00 00 00 00 00 ..À.....¤]......
0030: 00 00 00 00 00 00 00 00 80 07 00 00 38 04 00 00 ........€...8...
0040: 00 00 00 00 00 00 00 00 3e 00 00 00 80 07 00 00 ........>...€...
0050: 38 04 00 00 01 00 18 00 57 56 43 31 00 00 01 00 8.......WVC1....
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0070:|27 00 00 01 0f e3 7e 3b f2 1b 88 80 00 00 01 0e '....ã~;ò.ˆ€....
0080: 10 44 ef c8 6c 80 .DïÈl€

- Enumerated media type 0:

Video

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {31435657-0000-0010-8000-00AA00389B71}
formattype: TIME_FORMAT_NONE {00000000-0000-0000-0000-000000000000}
bFixedSizeSamples: 0
bTemporalCompression: 1
lSampleSize: 0
cbFormat: 0


However, Sonic Video Decoder *does* render it correctly.

[madshi]

I'm a bit confused. Isochroma, would you mind explaining why you aren't happy with the mkv file? I mean shouldn't everything be just fine once you have the mkv with a 24fps VC-1 stream inside? Why the AVS stuff? What purpose does it have? Thanks!

[Daodan]

@Isochroma
The muxing into mkv part doesn't work on ANY of the vc1 evos I have. I only get a mkv of a few kb, and that's it. Yes, tried your method and also other deviations and nothing. Is there something I also need that you did not specify?

[honai]

I just now realized something. Cyberlink ships their own VC-1 decoder w/ PowerDVD: %ProgramFiles%\CyberLink\PowerDVD\VideoFilter\vc1dc.dll

Could it be possible that all VC-1 video streams authored for HD-DVD aren't meant to be played by Microsoft's DirectShow filters? And because of that Cyberlink didn't just ship the WV9 runtime but had to write their own decoder? Same for InterVideo, they also have their own VC-1 decoder.

EDIT:

I also noticed that in the above dump biSizeImage = 65536, whereas in all other WVC1 sample files I have it's a value around 318603. What does that parameter do, and how is it derived?

[crypto]

@honai
Interesting thought. The same is true for Sonic.