Problems with WMV as DirectShowSource

[Redmondman]

This may be a FAQ, apologies, I've searched.

End-to-end goal: transcode a WMV (non-protected) to Tivo-compatible MPEG format for playback on Tivo Series 2.

Tool: Videora Converter for Tivo, which uses AviSynth. I can see that it builds an AviSynth script that references the WMV as a DirectShowSource. This should work, as far as I can tell. GSpot (2.21) examines the file and finds playable codecs. DSPlay (from WMSDK) plays the WMV file fine. However, MPlayer2.exe (media player classic) appears to throw the same error as AviSynth about a missing codec; upon further examination, the missing codec is identified as "Windows Media Audio 9.1 Professional". According to the MS web site, this codec should be already installed with WMP 10 (and in fact, WMP 10 plays the file perfectly). Note that just to cover my bases, I installed the Windows Media 9 VCM package. I can't seem to find any other source for this codec -- which I should already have!

All hints, pointers, better places to post, etc. appreciated.

[IanB]

You have to get MPlayer2 working first!

It should just phone home to M$, then download and install the missing bits and pieces.

Possible the DirectShow wrapper may be corrupt. Uninstalling WMP 10 may might poke it in the guts enough to get the download and install to work correctly.

Have a look in the audio encoding forum they will have tools to transcode your source to WAV so you can short circuit the problem.

[Redmondman]

Ian, thanks for the response.

Interesting results on PC #2. MPlayer2 did download codecs -- the WM9 VCM package that I had manually installed on PC#1. It then proceeded to play the video, but no audio. No error message this time, however. Videora Converter's logs (on PC#2) show "unsupported format" (same as PC#1).

At the moment, I've worked around the issue by using TMPGEnc 3.0 Xpress to transcode, but I like debugging, so I'm curious :). I may have a look at the DirectShowPlugin code.

[foxyshadis]

Hunting around DSS code won't really help. Graphedit would be a good place to troubleshoot, since it exposes the underlying workings of mplayer2 and DSS. Drag your file in and see what filters you get; add a few manually if the wrong ones show. I have no idea how to create a WMA Pro file myself, or I'd test, but the likely filters are Windows Media Audio Decoder and WMAudio Decoder DMO. I don't think WMAPro over S/PDIF would do it.

I suppose it might be that there's no DS wrapper for WMAPro, but I can't imagine that would be the case.

[Redmondman]

Foxy, thanks for the pointer to Graphedit, I'll check it out. I had already done this with Gspot and it identified precisely the filters you listed.

I went back to my original project (I had used Windows Media Encoder) and sure enough, the WME profile had WM Audio 9.1 Pro selected as the audio codec. (I do these projects once a year around holiday time and I tend to forget what I had done.) Ultimately you may be right -- no DS wrapper for WM 9.1 Pro.

Oh, so you should be able to play along if you download the encoder (http://www.microsoft.com/downloads/details.aspx?FamilyID=5691ba02-e496-465a-bba9-b2f1182cdf24&DisplayLang=en).

[Redmondman]

So I thought it would be fun to observe the codec download attempts while MPlayer2.exe tries to play the file. While I analyze these, I thought I'd post in case others are interested.

When playing the AVS (the file that simply references the WMV as a DirectShowSource), MPlayer2 reaches out to http://activex.microsoft.com/objects/ocget.dll (and later codecs.microsoft.com) for CLSIDs {32315659-0000-0010-8000-00AA00389B71} and {00000001-0000-0010-8000-00AA00389B71} (sites return 404 in each case).

Interestingly, this is different from the log when trying to play the source WMV directly in MPlayer2. In that case, the CLSIDs requested are: {00000164-0000-0010-8000-00AA00389B71} and {00000162-0000-0010-8000-00AA00389B71}.

The fact that there's a difference makes me want to trace through the DirectShowSource code; perhaps there's something in codec negotiation that I can find to account for the difference. (Not that this will make it start to work, but still interesting for my education.)

[Redmondman]

Looks like I've been barking up the wrong tree. Appears the problem is much more fundamental. Videora converter invokes ffmpeg to do the actual encoding. Videora converter passes the AVS file as input to ffmpeg. ffmpeg doesn't understand AVS scripts natively. I hadn't pursued that path since Videora converter is a wrapper program which installs AviSynth; I assumed that it would work.

I'll send them feedback.

[Pookie]

Hmmm...just about every version of ffmpeg built after Sept 06 should have Avisynth support built into it. Tell 'em to use Celtic_druid's builds...

[Redmondman]

Yes, they must have packaged an old build. Here's the version dump:

ffmpeg version 0.4.9-pre1, build 4747, Copyright (c) 2000-2004 Fabrice Bellard
configuration: --enable-memalign-hack --enable-mingw32 --enable-mp3lame --enable-gpl --enable-a52
built on Mar 21 2005 16:41:12, gcc: 3.4.2 (mingw-special)
ffmpeg 0.4.9-pre1
libavcodec 4747
libavformat 4621

[Redmondman]

Working with a newer build of ffmpeg (at least the encoding is in progress). Aplogies for the red herring -- not an issue with AviSynth after all.

[IanB]

{32315659-0000-0010-8000-00AA00389B71} = Video YV12
{00000001-0000-0010-8000-00AA00389B71} = Audio std Wav
(sites return 404 in each case). Not very surprising these are tail end formats, the renderers are supposed to support these.

{00000164-0000-0010-8000-00AA00389B71} = Audio subtype 164 :confused:
{00000162-0000-0010-8000-00AA00389B71} = Audio WMMEDIASUBTYPE_WMAudioV9

And as I said when Mplayer2 works DSS will work.