DirectShow with WPF MediaKit
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)
{
base.OnInitialized(e);
GraphPlayer = (GraphPlayer)MediaPlayerBase;
}
}
public class GraphPlayer : WPFMediaKit.DirectShow.MediaPlayers.MediaPlayerBase
{
public GraphPlayer()
{
//Using STA, because my application pops property windows.
EnsureThread(System.Threading.ApartmentState.STA);
}
/// <summary>
/// This method exposes a surface allocated renderer to the caller
/// </summary>
public IBaseFilter CreateRenderer(IGraphBuilder graph)
{
if (!CheckAccess())
{
Dispatcher.BeginInvoke((Action)(()=>CreateRenderer(graph)));
}
return CreateVideoRenderer(
WPFMediaKit.DirectShow.MediaPlayers.VideoRendererType.VideoMixingRenderer9,
graph);
}
}
SecureString: Soup to Nuts, Part II
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" ...>
…
<PasswordBox.InputBindings>
<KeyBinding Key="Enter" Command="{Binding ExecuteCredentialsCommand}"
CommandParameter="{Binding ElementName=_passwordBox}" />
</PasswordBox.InputBindings>
</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;
try
{
//authentication/persistence model code
}
finally
{
securePassword.Dispose();
}
},
//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 &&
!string.IsNullOrEmpty(UserName);
});
CredentialsChangedCommand = new DelegateCommand(
delegate
{
ExecuteCredentialsCommand.RaiseCanExecuteChanged();
});
}
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.