Jeff Griffin

Source

Posted on June 20, 2011

As requested, I have opened the full source for TranscodeToMP4. You can find it in my Blog repository on GitHub.

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 1.0.0.0
Source

Required:

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

Recomended:

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.

Options:

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)
	{
       	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);
	}
}