One of the things that a lot of DRM savvy CDNs are doing is to use WM Encoder to add WM DRM to their content without actually re-encoding. This is basically a copy operation from the input file (WMV) to an output file (WMV). The samples are never decompressed but rather passed directly through the Encoder. In the interim the Encoder can add WM DRM protection. This allows a very quick way to add WM DRM protection to a file without needing to re-encode, without any quality loss and without needing to protect the video on the server side with the WMRM SDK components. It’s a really a great way to get WM DRM protection enabled on the client.

The trick is to make sure that the input profile (the header information of the input file) matches the output profile (the profile you configure in the WM Encoder). This isn’t difficult to do but you do need to write a bit of code to do it. You can use the WMEncBasicEdit interface to generate a profile object that you can then use to feed back into the Encoder as the output profile. Using the WMEncBasicEdit object you can just grab the profile from the input file and tell the Encoder to use it to encode. The WM Encoder is smart enough to know that if the input and output profiles match that there is no reason to do any work and it doesn’t re-encode.

Unfortunately this method falls apart when using certain types of input files. If your input content happens to be interlaced, when you run your input file through this process you get corrupted output. The problem is that the profile that is extracted from the source file using WMEncBasicEdit doesn’t contain information about the interlaced nature of the source file. WM Encoder only checks that the basic input and output profile information matches. It doesn’t check to see if the input file was interlaced. Because of this WM Encoder tries to process the input content as if it were encoded using progressive frames. Since they are actually interlaced frames, the video that ends up in the output file plays back all garbled, distorted and corrupted. This is simply due to the fact that the WM Encoder is not setting the interlaced flag in the copied output. Theoretically if you could get the interlaced flag to be set correctly in the output file then the video would playback as expected. Unfortunately I haven’t found a good way of doing this.

I was able to confirm with the developers that currently own the WM Encoder 9 bits, that they are not interested in fixing this issue at this time. This is due to the fact that the WM Encoder 9 is at the end of its life and is being replaced with the Expression Encoder application.

The following link points to some VB.net WinForms / ASP sample code that I wrote years ago to demonstrate how to use this technique. I haven’t tried running this code since it was first written so it might not work out of the box. However, it should give you a starting point to enable you to create your own solution. The code can be found here: http://code.msdn.microsoft.com/DRMEncoderProfile