There are a few limitations to the supportability of the Windows Media Encoder 9 series application and SDK. Microsoft has extended support for this product for the next year or so. Hopefully if you are reading this you are aware of the next generation of the Encoder named the Expression Encoder. We are now on version 2 of the Expression Encoder and I would highly recommend that you take a look at it if you haven't already. We still have a large WM Encoder user base and the Expression Encoder is just starting to come into its own. This is the main reason why the WM Encoder support has been extended. I had the opportunity to talk to the Expression Encoder development manager the other day and we can expect about 85% feature parity between the WM Encoder and Expression Encoder with the release of Expression Encoder 3. This is as close as we are going to get. From what I understand we won't get 100% feature parity between the two products. However, the Expression Encoder will do a lot of stuff that the WM Encoder won't do. The Expression Encoder also has a full object model and SDK as of version 2, so it is fully programmable (although there are some issues with using VB .net that should be addressed in v2 SP1).
Not all of these limitations listed below are officially documented in a MS KB article. I’m calling them “official” because I’ve confirmed them with the developers in charge of maintaining the WM Encoder codebase (including the SDK bits). These limitations are not bugs but rather “by design”. Keep in mind that since the WM Encoder is at the end of its life, it is getting really difficult to get the guys that own this code to fix anything WM Encoder related. So even if you do find a bug and request a fix, it might be rejected. It just depends on the severity of the problem. Security issues will continue to be addressed.
Windows Media Encoder 9 SDK based application is not supported from an NT service
The big one for a lot of WM Encoder SDK developers is that Microsoft has decided to NOT support any applications written with the WM Encoder SDK and run from a Windows Service. Yep you heard that right, if you have a WM Encoder SDK based application and are running it from a Windows Service; you are doing so at your own risk. While it *might* work, if you run into any problems Microsoft isn't going to help you fix it until you pull all of your code out of the service exe and stick it into a standard desktop application. If you do this and are still having an issue MS is going to be more than willing to investigate the issue and if it turns out to be a bug you can request a fix. The reason for this is due to the fact that the WM Encoder engine uses hidden windows for various reasons. The limitations of the desktop when running from a service can cause various issues.
Only 4 simultaneous instances of the Windows Media Encoder 9 (SDK) are supported on a single machine
A lot of people are trying to run multiple encoding sessions on a single machine. With today’s multi-core machines this should be no problem. Unfortunately there are some known issues when running more than 4 simultaneous instances of the WM Encoder application or more than 4 simultaneous instances of any application using the IWMEncoder object or only 4 simultaneous instances of the IWMEncoder object within a single application. In other words you only get 4 simultaneous instances of the WM Encoder Engine per machine independent of the way the engine is being loaded. Again, you *might* be able to get more than 4 simultaneous instances to work but if you run into any problems you will be on your own. The reason for this is that WM Encoder uses various global resources. With each instance of the WM Encoder resource contention becomes an issue. We have found that when using more than 4 instances this contention can cause various issues.