WMA 5.1ch. in WMV only decodes to stereo?

[Isochroma]

I'm getting pretty angsty at M$ and their little games. 5.1-channel audio in wmv will only play back with all channels in Windows Media Player. All other applications, including graphedit, mpc, etc. can only get 2 channels from the WMAudio Decoder DMO.

Is there any way to get the 5.1ch. stream out and decode it?

[diogen]

You are probably using a DRM-ed clip/movie.
The player has to support MS DRM - of those I know only ZoomPlayer (WMV Edition) and TheaterTek.

Diogen.

[Isochroma]

Nope, it has no DRM. Plays just fine in MPC - with stereo audio only. This is a 'feature' reserved for WMP, just like hardware acceleration is. The clip plays at 65% CPU usage in WMP, while in MPC gets around 10 FPS (of 24).

[dohcmark8]

Try VLC or Media Player Classic.. 5.1 WMA works fine for me in them.

Doublecheck your setup, make sure you have 5.1 selected in speaker setup.

[guada 2]

@Isochroma,

NERO 7 is a good player for wma 5.1 pro.
I prefer it to Mpc and Vlc.

Make a few test audio stereo, and convert it with Canopus procoder 2 or Audition to 384 6CH.

Diogen
Thanks to TheaterTek :)

Bye.

[diogen]

Nope, it has no DRM. Plays just fine in MPC - with stereo audio only. This is a 'feature' reserved for WMP, just like hardware acceleration is. The clip plays at 65% CPU usage in WMP, while in MPC gets around 10 FPS (of 24).How do you output audio: analog or SPDIF? If digital, who's doing the DD/DTS real time encoding?

Diogen.

[Isochroma]

@dohcmark8:

WMA Pro multichannel plays fine in .wma files in all applications. However, M$ has specifically stated that only with Windows Media Player running on Windows XP will >2ch. audio coded in WMV be played back with its original channels.

Windows Media 9 Series: Feature Requirements (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmencode/htm/featurerequirements.asp)

[diogen]

You have to have WinXP to play discrete multichannel WMA Pro.
That's all there is in terms of limiting playback.

Diogen.

[Isochroma]

Then why does MPC not play back anything but two channels? And why does directshowsource() only decode two? And why does graphedit do exactly the same, using the default WM decoder directshow filters?

I have two possible explanations:

1. The default WMA decoder cannot decode more than 2 channels. Windows Media Player has a builtin decoder that handles WMA pro streams. Any other application which builds a playback graph will get the crippled Windows Media Audio Decoder filter.

2. The default WMA decoder can decode more than 2 channels. Like the Nero AVC decoder, it checks the application that has called it, and if it is not WMP, it outputs no more than two channels. It also checks the operating system version, and refuses >2ch. if it is not XP.

[diogen]

You make it sound like a conspiracy.
I'm playing WMVs (DRM-ed and not) using ZoomPlayer and TheaterTek with 5.1 WMA Pro using AC3Filter and digital out -
perfect DD 5.1 on the receiver. And there are a _lot_ of people like me. (Have not tried analog.)

Can you provide details of your configuration and procedure?

Diogen.

[Isochroma]

Windows XP Pro SP2
WMP 10 build 4019.
ffdshow-20060407-19H04-athlon

ffdshow is set to accept all YUV formats for input and RGB only for output (level fix for my video card). Other than that, nothing special.

You're using AC3Filter to convert the audio output to AC3 5.1-ch. Can you verify that it is not just upsampling 2-channel input? Try rendering your wmv file in graphedit. When the filter graph is built, right-click the directsound output module (last in the audio chain) and select Filter Properties. Check how many channels it is using.

[diogen]

...Can you verify that it is not just upsampling 2-channel input? When I look at AC3Filter properties in ZoomPlayer or Windows Media Player, it shows the matrix of channel mapping:
it is a 6x6 matrix with 1's diagonally - what comes in is sent out, no mixing. Green bars on all channels when present.

Diogen.

[lcx]

I just did a little test with a WMA 5.1 audio file.
Both MPC and Graphedit play 5.1 audio perfectly fine.

There must be something wrong with your setup.

[Isochroma]

@ICX: as I noted in the previous post, WMA files are not subject to this restriction. It is WMV video files which are.

[SeeMoreDigital]

I'm getting pretty angsty at M$ and their little games. 5.1-channel audio in wmv will only play back with all channels in Windows Media Player. All other applications, including graphedit, mpc, etc. can only get 2 channels from the WMAudio Decoder DMO.

Is there any way to get the 5.1ch. stream out and decode it? This has been my finding too - as discussed in other threads around the forum.

That said, it is possible to configure some settings in FFdshow and transcode 6Ch WMA streams to 6Ch AC3 "on-the-fly" ;)


Cheers

[Isochroma]

Ah, thanks for the info! I've decided that for now, I'll just leave the file in WMV format and proceed to more fertile production fields.

[zambelli]

Nope, it has no DRM. Plays just fine in MPC - with stereo audio only. This is a 'feature' reserved for WMP, just like hardware acceleration is. The clip plays at 65% CPU usage in WMP, while in MPC gets around 10 FPS (of 24).
Please don't spread FUD. Your making allegations based on nothing but very limited personal experience.

1) The only requirement for 5.1 WMA Pro playback is Windows XP. The feature is not reserved for WMP only. The only difference is that WMP uses WM Format SDK for all WMV/WMA playback, whereas MPC and most other apps use DirectShow. However, even DirectShow can decode the full 8 channels of WMA Pro when using the WMA decoder DMO. I just verified that myself using MPC, so clearly I'm not making this up.

2) Video hardware acceleration is not an exclusive feature of WMP either. The API is public, and it's called DirectX Video Acceleration (DXVA). In order for DXVA decoding to work, DXVA needs to be implemented on both codec level and driver level. The WMV decoder has a registry key that enables/disables DXVA decoding. Once enabled, DXVA decoding should work for any app using the WMV decoder, regardless of whether it's WMP, Zoom, MPC or Graphedit.

As for your 5.1 decoding problem... Have you made sure your speakers are set to 5.1 in the Control Panel? The codec checks that in order to know whether to output 5.1 or mix down to 2.0.

[Isochroma]

Before you accuse me of FUD, zambelli, you should realize that I can document every word that I have posted on this forum. The evidence is on my machine and I will provide further information if necessary.

Regarding WMV acceleration, I would certainly appreciate knowing which registry key enables all applications to make use of hardware WMV decode acceleration.

You might also, if you have time, explain why I have to input a special registry key (not something the average user will ever know about or be confident in doing) to enable this feature ("not an exclusive feature of WMP" in your words) to function in applications other than Windows Media Player?

[foxyshadis]

Well, the player apps could probably set that key themselves on install or first run, or on configuring for it, if someone were to convince them to. If zambelli lets us know (or I find it on msdn), I'll let blight know.

[zambelli]

Before you accuse me of FUD, zambelli, you should realize that I can document every word that I have posted on this forum. The evidence is on my machine and I will provide further information if necessary.
I'm not sure what that would prove. You have stated that WMA multichannel decoding is an exclusive feature of WMP, even though myself and others here have told you we have WMA multichannel decoding working just fine in other players. So either we're all lying to you (for what reasons?), or you're spreading FUD that's based on pure speculation.

Regarding WMV acceleration, I would certainly appreciate knowing which registry key enables all applications to make use of hardware WMV decode acceleration.
Actually, the key might not even be necessary, now that I think about it. I think WMV decoder has DXVA support enabled by default, but there is a reg key that can explicitly enable/disable it.
To force enable:
in HKCU\Software\Microsoft\Scrunch\WMVideo
create DWORD value "DXVA" and set it to 1.

Needless to say, make sure you actually have an ATI or Nvidia card that supports DXVA-WMV and latest drivers. At this time only WMV9 is supported in Nvidia, and WMV8 and WMV9 decoding in ATI released drivers.

You might also, if you have time, explain why I have to input a special registry key (not something the average user will ever know about or be confident in doing) to enable this feature ("not an exclusive feature of WMP" in your words) to function in applications other than Windows Media Player?
Actually, even WMP10 didn't ship with DXVA-WMV support, even though the decoder supported it. DXVA-WMV came aboard fairly late in the game for WMP10 release. ATI & Nvidia were just coming out with beta driver support, and there were some unresolved issues with accelerated playback in the WM SDK pipeline. So the decision was made to disable DXVA-WMV decoding in WMP10 and ship it later as an update. That update was released as QFE 888656 (http://support.microsoft.com/kb/888656/). The QFE enabled DXVA support that was actually already present in the decoder and fixed the WM SDK playback issues. It was never designed as a "WMP exclusive" feature, but there is a possibility that it was disabled in the original WMP10 release because the driver support wasn't mature enough.

[Isochroma]

My AGP FX5200 does support DXVA. I can play a certain wmv file in WMP with 30% CPU, while in mpc it is 65%.

I added the registry key (but did not reboot - is this necessary?) and observed no change in CPU usage in MPC.

One interesting tidbit about my video card - it has bad output levels when it is fed any YUV format. After many months trying to figure out why some decoders' output seemed so much better-looking than others, I was informed of this.

It turns out that ffdshow can be set to place itself between the final output of a decoder filter and renderer if the decoder outputs any YUV format. In this case, ffdshow does the colorspace conversion in software, and everyone's happy.

Any application which uses the regular process of directshow graph-building will, if the decoder outputs any YUV format, end up using ffdshow for final processing. The little ffdshow icon shows in the tray too.

So this morning I loaded the wmv file into WMP and... no ffdshow icon in the tray! Bad levels! Weird, eh? It seems that WMP does not use the standard system method for building these filter graphs, at least when the file contains wm video/audio.

Also, I found this interesting document, which seems to substantiate the view:

Enabling DirectX Video Acceleration (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmform95/htm/enablingdirectxvideoacceleration.asp)

From the above article:

"Because Windows Media Player was designed before the QASF filters had been developed, Windows Media Player has its own source filter, based on the Windows Media Format SDK, for playing Windows Media-based content. The WMP Windows Media Source Filter delivers decompressed data downstream directly to the audio and video renderers."

This would explain both the audio channel issue (which others have reported as well) and the DXVA video issue. WMP uses its own custom decoders which deliver the decoded stream directly to the output renderers, bypassing most or all of the standard directshow filters.

This allows WMP to implement certain extended features, like multichannel WMAPRO in WMV and DXVA video decode acceleration that other applications will never be able to use.

It seems likely the system WMV and WMA decoders are incapable of DXVA and multichannel PRO decoding, respectively.

[zambelli]

My AGP FX5200 does support DXVA. I can play a certain wmv file in WMP with 30% CPU, while in mpc it is 65%.
That's faulty logic. Something along the lines of:
1: My cat can fly.
2: Birds have wings, but dogs don't.
Conclusion: My cat is a bird.

I was under the impression that Nvidia started supporting DXVA-WMV with the 6xxx series. Can you point me to a Nvidia document that says 5200 supports DXVA assisted decoding of WMV9?

I added the registry key (but did not reboot - is this necessary?) and observed no change in CPU usage in MPC.
The difference in CPU load between WMP and MPC can be attributed to the fact that WMP uses WM SDK for playback, while MPC uses DirectShow for playback. DirectShow has to wrap DMO-type decoders, so that's an additional overhead. Furthermore, you seem to have ffdshow in your pipeline too, which is yet another filter in your DShow WMV decoding chain.

It turns out that ffdshow can be set to place itself between the final output of a decoder filter and renderer if the decoder outputs any YUV format. In this case, ffdshow does the colorspace conversion in software, and everyone's happy.
Any application which uses the regular process of directshow graph-building will, if the decoder outputs any YUV format, end up using ffdshow for final processing. The little ffdshow icon shows in the tray too.

And if ffdshow is being placed between the decoder and the renderer, then DXVA can't be used. You'll find that to be the case with MPEG-2, H.264 and WMV hardware decoding. DXVA requires the decoder to send raw data directly to the hardware - and then back to the renderer. If another filter is inserted between the decoder and renderer - then that filter forces a conversion to uncompressed video, making DXVA unusable.

So this morning I loaded the wmv file into WMP and... no ffdshow icon in the tray! Bad levels! Weird, eh? It seems that WMP does not use the standard system method for building these filter graphs, at least when the file contains wm video/audio.
No, it does not. I already told you in a previous post that WMP uses the WM SDK for all WMV/WMA playback. That's no big secret, as it's clearly documented in MSDN and has been since WMP7 came out in 2000.

This would explain both the audio channel issue (which others have reported as well) and the DXVA video issue. WMP uses its own custom decoders which deliver the decoded stream directly to the output renderers, bypassing most or all of the standard directshow filters.
No. Read again. WMP doesn't use custom decoders. It uses the same WMV decoder DMO as MPC or any other DShow player, the key difference being that the WM SDK uses the decoder DMOs directly, whereas in a DShow graph they must be wrapped.

This allows WMP to implement certain extended features, like multichannel WMAPRO in WMV and DXVA video decode acceleration that other applications will never be able to use.
It seems likely the system WMV and WMA decoders are incapable of DXVA and multichannel PRO decoding, respectively.
And it seems to me that you are a very stubborn person who refuses to listen. Several people in this thread alone have said that WMA 5.1 decoding works fine for them in players other than WMP. If your claim is true, then are they all mad? A Microsoft conspiracy?

I think I'm wasting my time here. Look at the attached screenshot. If that and everything I said to you here isn't proof enough - then I think there's no hope you'll ever change your mind.

[Isochroma]

65% was with ffdshow disabled. It seems hard to believe that the generic directshow decoder takes twice the CPU of WMP's internal one? Perhaps you are right.

I guess I should wrap up this thread by thanking you for your time providing the info. Clearly I'm just too paranoid for my own good :) I am stubborn. Maybe someday I'll be a lawyer?

Maybe someday DivX and XviD will get hardware-assisted decoding.

[zambelli]

65% was with ffdshow disabled. It seems hard to believe that the generic directshow decoder takes twice the CPU of WMP's internal one? Perhaps you are right.
Since the decoder is the same in both cases, the overhead must be in the rest of the pipeline. I agree that the difference is too great. I'd expect 5%, 10% at most. Can you load a WMV file in GraphEdit and send a screenshot of the graph?

I guess I should wrap up this thread by thanking you for your time providing the info. Clearly I'm just too paranoid for my own good :) I am stubborn. Maybe someday I'll be a lawyer?
Well, I'm just glad you saw the light after all. :)

Maybe someday DivX and XviD will get hardware-assisted decoding.
Video card manufacturers are already implementing H.264 acceleration, so it's unlikely they'd go back and implement MPEG-4 ASP. It'd seem like a step backwards.

BTW, in case you ever want to check DXVA capabilities of your video card, here's how you do it:

1. Run dxdiag.exe
2. Choose "Save All Information".
3. Open the exported dxdiag.txt file.
4. Search for text "Video Accel".

You should find a line that says something like:
ModeMPEG2_C ModeMPEG2_D ModeWMV9_B ModeWMV8_A ModeWMV9_A

[Isochroma]

Thanks for the dxdiag info!

Here's the modes my card does:

Video Accel: ModeMPEG2_A ModeMPEG2_B ModeMPEG2_C ModeMPEG2_D

So it looks like it only has MPEG-2 acceleration. MPEG 2 iDCT is so similar to MPEG-4 ASP/AVC that it might be possible to use this capability for more advanced codecs...

[Isochroma]

Looks like some others are also having this problem:

directshow and audiochannels (http://forum.doom9.org/showthread.php?p=844659#post844659)

[IanB]

...
wFormatTag 65534
...
Audio: Windows Media Audio 44100Hz 6ch 256kbps [Raw Au...Pretty much say it all. It is simply not outputing WAVE_FORMAT_PCM = 1

[zambelli]

Pretty much say it all. It is simply not outputing WAVE_FORMAT_PCM = 1
But subtype is MEDIASUBTYPE_PCM. Here are the full properties of the WMA Decoder out pin:

Audio: WAVE_FORMAT_EXTENSIBLE 48000Hz 6ch 6912Kbps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Audio {73647561-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_PCM {00000001-0000-0010-8000-00AA00389B71}
formattype: FORMAT_WaveFormatEx {05589F81-C356-11CE-BF01-00AA0055595A}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 0
cbFormat: 40

WAVEFORMATEX:
wFormatTag: 0xfffe
nChannels: 6
nSamplesPerSec: 48000
nAvgBytesPerSec: 864000
nBlockAlign: 18
wBitsPerSample: 24
cbSize: 22 (extra bytes)

WAVEFORMATEXTENSIBLE:
wValidBitsPerSample: 24
dwChannelMask: 0x0000003f
SubFormat: {00000001-0000-0010-8000-00AA00389B71}

pbFormat:
0000: fe ff 06 00 80 bb 00 00 00 2f 0d 00 12 00 18 00 þÿ..€».../......
0010: 16 00 18 00 3f 00 00 00 01 00 00 00 00 00 10 00 ....?...........
0020: 80 00 00 aa 00 38 9b 71

[crypto]

Same effect here. Graphedit plays a 6-ch wma downmixed to 2-ch. WMP plays the same 6-ch wma ok on 6-ch.

zambelli:
1. Can you check on graphedit playing a 6-ch wma w/ renderer properties open? Do you get 6-ch?

2. Which cool tool did you use to dump the full properties?

[IanB]

Okay that is more or less what I expect to have offered....
SubFormat: KSDATAFORMAT_SUBTYPE_PCM {00000001-0000-0010-8000-00AA00389B71}
...It just doesn't seem to happen. I'll have to test some more.

[bond]

moved to audio forum

[zambelli]

1. Can you check on graphedit playing a 6-ch wma w/ renderer properties open? Do you get 6-ch?
No, I get 2ch in GraphEdit too. I wonder if it has something to do with the default settings of the filter. Perhaps a special flag needs to be set when building the graph in order to request 6 channels from the WMA decoder, and by default it's set to 2. I'll have to dig through some MSDN docs to verify.

The bottom line is that it's possible to get 6ch in DirectShow, because obviously MPC and Zoom Player and others are doing it. The only question is how does one specifically request it from the decoder.

2. Which cool tool did you use to dump the full properties?
Media Player Classic by Gabest. Menu Play --> Filters --> WMA Decoder DMO.

[crypto]

Thanks for taking the time to check and the tip regarding the full properties.

[mrcorbo]

No, I get 2ch in GraphEdit too. I wonder if it has something to do with the default settings of the filter. Perhaps a special flag needs to be set when building the graph in order to request 6 channels from the WMA decoder, and by default it's set to 2. I'll have to dig through some MSDN docs to verify.

The bottom line is that it's possible to get 6ch in DirectShow, because obviously MPC and Zoom Player and others are doing it. The only question is how does one specifically request it from the decoder.


This (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmform95/htm/usinghighdefinitionaudio.asp) seems to be the info you are looking for.

And here (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wmform95/htm/audiodecodingproperties.asp) is a page listing all of the codec properties.

Aside from setting the g_wszWMACHiResOutput property to "TRUE" it may also be necessary to set the g_wszWMACSpeakerConfig property to "DSSPEAKER_DIRECTOUT" to prevent downmixing in the deocder.

[crypto]

mrcorbo:
That seems to be it, great find.

The question remains, why the codec has been designed that way. You have to fiddle around with some internal stuff, that is not even exposed by a property page. All other codecs I know play back what they get by default. For me, the reason is obvious. This scheme fits in the global MS strategy.

[zambelli]

The question remains, why the codec has been designed that way. You have to fiddle around with some internal stuff, that is not even exposed by a property page. All other codecs I know play back what they get by default. For me, the reason is obvious. This scheme fits in the global MS strategy.
ALL Windows Media codecs are designed so that you can set the properties directly on the codecs. The APIs are all well documented. What exactly is the problem?

[crypto]

There is no problem thanks to your help and MSDN, just an open point. I asked why the filter is defaulting to 2-ch downmix. A rhetorical question, that I answered myself.

[Wilbert]

Aside from setting the g_wszWMACHiResOutput property to "TRUE" it may also be necessary to set the g_wszWMACSpeakerConfig property to "DSSPEAKER_DIRECTOUT" to prevent downmixing in the deocder.
Forgive me ignorance. Where i can set these properties (in the registry somewhere?)?

[crypto]

Forgive me ignorance. Where i can set these properties (in the registry somewhere?)?

They cannot be set in the registry. They have to be set programmatically through the IPropertyBag interface. Thus they are out of reach to the user.

[IanB]

@mrcorbo,

Thank you very much. This is exactly the piece of information we have all been looking for. :D :D :D

[mrcorbo]

Glad I could help. This behavior is strange, but maybe it is to allow backwards compatability with older apps that might not be expecting >2 channel/16bit audio? Just trying to avoid the conspiracy theories here :D

[zambelli]

Glad I could help. This behavior is strange, but maybe it is to allow backwards compatability with older apps that might not be expecting >2 channel/16bit audio? Just trying to avoid the conspiracy theories here :D
Most player applications have the ability to control the DShow graph they're building, so it would make sense that negotiating the number of audio channels would be up to the player app.

[crypto]

Most player applications have the ability to control the DShow graph they're building, so it would make sense that negotiating the number of audio channels would be up to the player app.

Agreed :)

[mrcorbo]

Most player applications have the ability to control the DShow graph they're building, so it would make sense that negotiating the number of audio channels would be up to the player app.

Having these settings inaccesable from a property page or a registry setting effectively limits this codec's use (at least with full functionality) outside of applications that have code written explicitly to handle it. Shouldn't the ideal be for any properly written DShow player to "just work" with any properly written DShow codec without having to have any knowledge of the inner workings of that codec?

The problem with this design is manifested pretty clearly in the case of GraphEdit. There is absolutely no way to get GraphEdit to play back WMA9pro in multichannel or 24bit and any other DShow player that doesn't specifically take WMA playback into account will behave the same way.

I can accept this if it was done out of neccessity, such as the compatability reason I speculated on. After all, Microsoft does have a responsibility to support developers who have chosen to specifically support WM technologies in the past. But to state that this design is in any way desirable is just flat out wrong.

[zambelli]

Having these settings inaccesable from a property page or a registry setting effectively limits this codec's use (at least with full functionality) outside of applications that have code written explicitly to handle it. Shouldn't the ideal be for any properly written DShow player to "just work" with any properly written DShow codec without having to have any knowledge of the inner workings of that codec?
I think you're forgetting that DirectShow is an API - an application programming interface. So no, it wasn't designed to be user friendly - it was designed with developers in mind. It's kinda like saying "DirectX should have a friendly user interface so I can control the pixel shading properties of each graphics application". That's not what APIs are about.

Yes, a well designed DShow filter should work "out of the box" with its default settings. WMA Decoder does that - it just happens to default to stereo decoding, which is desired behavior for probably >90% of users. It's up to the player app to take care of correctly configuring the decoder based on the format and environment.

The problem with this design is manifested pretty clearly in the case of GraphEdit. There is absolutely no way to get GraphEdit to play back WMA9pro in multichannel or 24bit and any other DShow player that doesn't specifically take WMA playback into account will behave the same way.
I can accept this if it was done out of neccessity, such as the compatability reason I speculated on. After all, Microsoft does have a responsibility to support developers who have chosen to specifically support WM technologies in the past. But to state that this design is in any way desirable is just flat out wrong.
GraphEdit is an SDK test application - not a player. A real player app should take the media format into account when configuring the decoder. That's how it works: the player app provides the shiny UI and builds the correct graph, and DShow does all the heavy lifting underneath.

Sure, many DShow filters have property pages which let you configure the default settings for the filter. Good for them, but that's going beyond the call of duty. I don't think relying on APIs to be just APIs is "flat out wrong".

[mrcorbo]

I think you're forgetting that DirectShow is an API - an application programming interface. So no, it wasn't designed to be user friendly - it was designed with developers in mind. It's kinda like saying "DirectX should have a friendly user interface so I can control the pixel shading properties of each graphics application". That's not what APIs are about.

This is completely outside the issue. We're not talking about how DShow operates, we're talking about how one specific decoder object operates. I'm not taking issue with having a programmatic interface to features in this or any other codec. What I am taking issue with is the reduced functionality unless the player application takes this individual codec's API into account. To me this is counterproductive to having a unified media framework.

Yes, a well designed DShow filter should work "out of the box" with its default settings. WMA Decoder does that - it just happens to default to stereo decoding, which is desired behavior for probably >90% of users. It's up to the player app to take care of correctly configuring the decoder based on the format and environment.

FYI, not just stereo decoding, but 16 bit as well. Also FYI, Windows Media Player 9 (and I'd imagine 10 and 11) are hardcoded to enable HD audio playback. Since a large portion of your cited 90% are probably using WMP as their player application, I question then why WMP has specifically been coded to not exhibit this "desired behavior" and in fact doesn't even have a setting in the player to enable it.

GraphEdit is an SDK test application - not a player. A real player app should take the media format into account when configuring the decoder. That's how it works: the player app provides the shiny UI and builds the correct graph, and DShow does all the heavy lifting underneath.

Sure, many DShow filters have property pages which let you configure the default settings for the filter. Good for them, but that's going beyond the call of duty. I don't think relying on APIs to be just APIs is "flat out wrong".

Other companie's DShow filters have property pages to configure settings as a convenience to the end user and as a recognition of the fact that the developers of DShow player applications (of which Microsoft with WMP is most prominent) are unlikely to write specific code just to be able to fully utilize their codec. Imagine the mess WMP would be if it had to include code written to handle the properties of each DShow filter out there. No, what happens is the exact opposite. Most filters are specifically written to be fully functional when used with WMP without the WMP developers having to even know that that filter exists. And IMO, this is exactly the way filters should behave. Those that don't behave this way, generally are provided as parts of applications where the developer doesn't necessarily support or encourage the use of their filters outside of that application.

[IanB]

Having to poke codec attributes to have that codec offer "high definition" pin connection formats is pretty Direct Show unfriendly, particularly for users of simple straight forward functions like IGraphBuilder::RenderFile.

Unless I have been sadly mistaken for many years about how Direct Show components interoperate, I expect the Direct Show friendly way to operate is to repeatadly offer pin connections until accepted, starting with the "best" format available and ending with the most compatible. The input pin should simply reject connection attempts it can't handle and finally accepts the one it can handle.

This proven technology still serves extremely well in the video part of Direct Show and is equally applicable for all Direct Show data formats. I have to wonder why Microsoft are steering away from such a succesfull model towards one that has obviously very poor future feature compatibility.

Yes Graphedit is a test harness, one that has been invaluable for learning how to build and experiment with then write and debug Direct Show Graphs and the Direct Show components. Unfortunatly now it lacks the ability to poke the property bag interfaces. So I have to wonder how well tested is this element of software.

[IanB]

What happened to the JRBurke post ????

[Wilbert]

He removed it.

[JRBurke]

In case anyone needs it, here's the basic part of the code that worked for me. Originally I was just using "render file".

IGraphBuilder *pGraph;
HRESULT hres;
IBaseFilter * pDmoFilter;

hres = CoCreateInstance(CLSID_DMOWrapperFilter, NULL,
CLSCTX_INPROC, IID_IBaseFilter, (void **)&pDmoFilter);

IDMOWrapperFilter *pWrap;
pDmoFilter->QueryInterface(IID_IDMOWrapperFilter, (void **)&pWrap);

hres = pWrap->Init(CLSID_CWMADecMediaObject, CLSID_CWMADecMediaObject);

pWrap->Release();

IPropertyBag *pPropertyBag = NULL;
hres = pDmoFilter->QueryInterface(IID_IPropertyBag, (void**)&pPropertyBag);

hres = SetHiResOutput(pPropertyBag);

hres = pGraph->AddFilter(pDmoFilter, L"WMA Filter");

hres = pGraph->RenderFile(FileName, NULL);


HRESULT SetHiResOutput(IPropertyBag* pBag)
{
HRESULT hr = S_OK;

VARIANT myVar;
VARIANT myVar2;
VariantInit(&myVar);
VariantInit(&myVar2);

myVar.vt = VT_BOOL;
myVar.boolVal = TRUE;

myVar2.vt = VT_I4;
myVar2.iVal = DSSPEAKER_DIRECTOUT;

hr = pBag->Write(g_wszWMACHiResOutput, &myVar);
hr = pBag->Write(g_wszWMACSpeakerConfig, &myVar2);

return hr;
}