Jeff Griffin

Transcode to MP4

Posted on May 10, 2011

A few weeks ago, I talked about playing with WPF and DirectShow with WPF MediaKit.  I wanted to finish a video transcoder project I had laying around for some time.  Originally, it was a very simple WinForms app that guides the process of building a graph in DirectShow to extract the audio and video streams from some video file source, send them through some other compressor (or not), and place them in an MP4 container.  The goal was to allow my wife to convert the files from her camera, so she could post them on YouTube (She didn't want to use GraphEdit, imagine that).  At the time, HandBrake didn't exist, or wasn't available on Windows and there were plenty of paid options, but I figured I could mock up a solution at a similar cost.  That was true, until I moved it to WPF and added a video preview, but whatever, it was fun.  This is the result:

Transcode to MP4 - Version


Haali Media Splitter: Actually, only the MP4 Multiplexer is required, but the splitter is a handy file source, supporting many formats.

.NET 4.0 Client Profile


FFDShow Tryouts: This adds a ton of functionality and customization, through the filter settings dialogs. See Issues and Solutions below.

MONOGRAM AAC Encoder: This is my own build of this filter.  I found this and a number of other GPL and LGPL based DirectShow filters at RadScorpion's blog.  I wanted to use this filter, but it doesn't register as an Audio Compressor in DirectShow, which this Transcoder requires.  If you would like the source for my changes, please don't hesitate to ask.

There are a number of other filter options you can experiment with, and of course your mileage may vary.  Also, this program will attempt to allow you to make any decision you want about what codecs you would like to use.  That doesn't mean that the MP4 Multiplexer or your video player of choice will appreciate the decision you made, and this program does not protect you from this.


The Show Preview option can be found in the render options menu.  Some filters don't work so nicely with the Pin Tee Filter, which is used to show a video preview during the encoding process.  Turning off the Show Preview option lets this program build a graph without including the Pin Tee and Video Renderer.  Media Center filters will require the Show Preview setting to be off.

The Use Clock option is the same as the one found in GraphEdit.  It will generally allow the graph to progress at or below the speed of playback.  You should always try leaving this option off for the sake of speed, but some filters don't appreciate being rushed.

Clicking on the gear icon next to the selected decoder filter will pop the filter's configuration dialog (if it has one).  These are implemented by the filter's vendor.

Issues and Solutions:

I found out while testing this with the filters Media Center uses with WTV and DVR-MS files that some files aren't so happy working outside the bounds of their original intent.  I did have success transcoding these formats, however, by turning off the Show Preview option.

In testing with FFDShow Tryouts, files with MPEG audio streams tended to halt or crash the program.  This was corrected by going into the FFDShow Audio Decoder Configuration in the start menu, and under Codecs, I switched the MP1,MP2 decoder from libmad to libavcodec.

Why not just use HandBrake now?

By all means, you should if it suits your needs.  HandBrake offers tons of options, is relatively user friendly and doesn't require all this mucking about with DirectShow filters.  If it were out when I wrote the first pass of this, I would have had no motivation to write it.  However this is an extremely open-ended tool, so if you need to transcode something that handbrake doesn't support, but for which there are DirectShow filters available, you can use this as an alternative to GraphEdit.  Media Center files are a good example of this.

Please leave me a feedback if you are experiencing issues using this tool, you have feature requests, or other questions.

DirectShow with WPF MediaKit

Posted on April 25, 2011

Lately, I have been tweaking and old video file transcoding application, so I can post it here.  I'll get into the program itself in more detail once I'm done adding some functionality.

For those of us who still have some unfinished business in the world of DirectShow, as well as those building new software with Media Foundation, Jeremiah Morrill's work with the WPF MediaKit can be a helpful tool.  The intent of this library seems to be to provide pluggable media presenters for a number of use cases like DVD content, generic URI content, video capture devices, Direct3d renders, etc. If these cases fit your needs, dropping the appropriate element into your XAML will be a negligible task. In my case, the bulk of the graph is built in code that isn't concerned with the UI, and all I needed was a surface allocated renderer to plug into my existing pipeline architecture.  Once I found the right way to use the aspects of the Media Kit that I needed, the code to expose them was simple.

The first thing I had to understand was that Jeremiah's player classes inherited from a WorkDispatcherObject that encapsulated his own WorkDispatcher class, which handles delegate queuing and invoking and hosts a message pump.  It's a nice implementation, so I had no problem incorporating it into my model code, which handles the pipeline's topology.  Allowing two WorkDispatcherObjects to share a dispatcher required a small modification to the kit: The Dispatcher property on WorkDispatcherObject needed to be made protected, rather than private. Changing the dispatcher of a WorkDispatcherObject that has already started its dispatcher's thread can have some unintended results. It wouldn't be too tough to write a WorkDispatcherObject that could support setting the dispatcher more gracefully, but this works for me as long as I'm careful about when I set it.  Since the player object is instantiated as a result of UI initialization and immediately starts a thread on the dispatcher, it was much simpler to allow the ViewModel code to borrow the View's dispatcher, using a OneWayToSource binding.

<Local:GraphPlayerElement GraphPlayer="{Binding GraphPlayer, Mode=OneWayToSource}"/>

The entire player is bound, rather than just the WorkDispatcher, because the ViewModel/Model will need it to call CreateRenderer.  Here is the code for the player and the element used to host it:

public class GraphPlayerElement : MediaElementBase

	protected override WPFMediaKit.DirectShow.MediaPlayers.MediaPlayerBase OnRequestMediaPlayer()
		return new GraphPlayer();

	public static readonly DependencyProperty GraphPlayerProperty =
		DependencyProperty.Register("GraphPlayer", typeof(GraphPlayer),
		typeof(GraphPlayerElement), new PropertyMetadata());

	public GraphPlayer GraphPlayer
		get { return (GraphPlayer)GetValue(GraphPlayerProperty); }
		set { SetValue(GraphPlayerProperty, value); }

	protected override void OnInitialized(EventArgs e)
		GraphPlayer = (GraphPlayer)MediaPlayerBase;

public class GraphPlayer : WPFMediaKit.DirectShow.MediaPlayers.MediaPlayerBase
	public GraphPlayer()
		//Using STA, because my application pops property windows.

	/// <summary>
	/// This method exposes a surface allocated renderer to the caller
	/// </summary>
	public IBaseFilter CreateRenderer(IGraphBuilder graph)
		if (!CheckAccess())

		return CreateVideoRenderer(

SecureString: Soup to Nuts, Part II

Posted on April 11, 2011

My last post, SecureString: Soup to Nuts, Part I, dealt with some basic rules around using the SecureString class in .NET and how to prepare the secret stored inside for persistence, without exposing the clear text to a CLR type.  In the second part, I'm going to discuss my solution for maintaining SecureString best practices, without sacrificing our MVVM design principles.  The XAML and code provided is in WPF, but it's applicable to Silverlight, as well with minimal tinkering.

First let's talk about PasswordBox.  The PasswordBox was designed to obscure the user-entered text, both visually and in memory.  That is to say, visually, it's much like the old Windows Forms MaskedTextBox, except it's specifically designed for secret data, and will only expose said secret in a clear text string if asked to do so,via the Password property.  It's important to understand that the Password property is only a helper that accesses the encrypted data member.  For this reason, it is not exposed as a DependencyProperty.  This is a source of frustration to developers who have no designs on a SecureString solution.  Alas, there's no pleasing everyone, and a Password DependencyProperty would make an acceptable SecureString implementation impossible with PasswordBox.  If you Google "PasswordBox MVVM" (without the quotes) you will find that the generally accepted solution for the CLR string camp, makes use of an attached property to expose a CLR string for binding.  This effectively takes the MaskedTextBox functionality of PasswordBox, and passes on memory security.

We want an MVVM solution that hands us a SecureString, so let's look at the SecurePassword property.  More frustration, as this is also not a DependencyProperty.  Before you go angrily writing an attached property to expose the SecureString, understand that this is by design, not neglect.  The first commandment of SecureString is to dispose of it when you're finished right?  The SecurePassword property gives us a SecureString to use one time, then dispose of it.

The MVVM way to do this is now staring us in the face.  We need to bind the event we're going to use to execute our users' credentials to an ICommand.

<PasswordBox x:Name="_passwordBox" ...>
                <KeyBinding Key="Enter" Command="{Binding ExecuteCredentialsCommand}"
                                 CommandParameter="{Binding ElementName=_passwordBox}" />
<Button Content="Login Button Text" …
        Command="{Binding ExecuteCredentialsCommand}"
        CommandParameter="{Binding ElementName=_passwordBox}"/>

In this example's ViewModel, I'm using Prism's DelegateCommand implementation of ICommand.

public ViewModelClassConstuctor(IRegionManager regionManager,
	IProxyDataProvider dataProvider)
	ExecuteCredentialsCommand = new DelegateCommand(
	//execute method
	delegate(object parameter)
		SecureString securePassword = parameter as SecureString;
		if (parameter is PasswordBox)
			securePassword = ((PasswordBox)parameter).SecurePassword;
			//authentication/persistence model code

	//can execute method
	delegate(object parameter)
		SecureString securePassword = parameter as SecureString;
		if (parameter is PasswordBox)
                        	securePassword = ((PasswordBox)parameter).SecurePassword;
		return securePassword != null && securePassword.Length > 0 &&
	CredentialsChangedCommand = new DelegateCommand(

public DelegateCommand ExecuteCredentialsCommand { get; private set; }
public DelegateCommand CredentialsChangedCommand { get; private set; }

There you have it. With the code from the previous entry, you can generate a nice authentication prompt with password persistence, without sacrificing memory security or your MVVM design. I hope this has been a helpful guide. Please leave a comment if you liked it, have something you'd like to share, or if you thought it could have been more comprehensive.