Dowitchers, the DirectShow .net rewrite project.

Dowitchers?

I'm sure you can figure that out. It's a kind of bird by the way.

Choose your favorite .net language! C# is the ideal pick of course, Visual Studio's implement interface and abstract classes feature is not available for C++, sadly. But it's certainly possible to write filters in any supported language. C++ has the unique ability to mix native code with managed, not a bad thing if you need performance for image processing.
No COM, no QueryInterface, no references, especially there are no circular references. It's like having xmas every day in the year.
New baseclasses. Creating filters has never been easier.
Graph-less. Filters do not even have any access to the graph, they can be manually connected and controlled, if you wish.
Open source by nature (Reflektor...). Have you ever wondered why your DirectShow application crashes or deadlocks, but couldn't debug into the quartz dlls?
Built using the basic .net class library, it might not just run on Windows in the future. There are only a couple of system dependencies, Managed DirectX 1.1 for rendering (any cross platform OpenGL for .net? what about audio?) and winmm.dll for timing.
Simple media types. There is just one guid to check instead of three. Legacy insanities like negative image height is not allowed. Pitch for image types is included in the format description.
Filter registration replaced by a dll plug-in system. Search paths can be setup for the graph and/or filters can be added for intelligent connect run-time, everything is configurable per application.

NewSegment and EndOfStream are also packed into samples and travel through Receive. There is no need to sync more functions with critical sections.
This also means that these samples have to be passed downstream for the graph to work correcly, just like forwarding their counterpart calls in DirectShow.
Allocators are gone. Samples are generated by the upstream filter *, every transform filter is in-place by default unless it copies the data to a new sample.
* In DirectShow it was common for renderers to give the upstream filter a device mapped buffer to write to, since it had a couple of problems (a few decoders expected to get back the same buffer and just copied the difference, or effect filters tried to read and manipulate the pixels in the slower video memory) and it isn't really possible in managed code, renderers should just mashal the bytes to an IntPtr now. Not having a pool of samples in the allocator is less efficient, but without reference counting it is impossible to implement the way DirectShow did (refcnt reaching 0 put the sample back to the queue instead of freeing the object, violating COM rules a bit). However, the GC does a good job immidiatelly freeing the samples as they are not needed. Sending an empty 1920x1080 YV12 image to the D3D renderer used 20-30% CPU on an old AMD 3500+ (but Rgb32 maxed it out), Marshal.Copy had a 500 MB/s bandwidth from byte[] to the IntPtr of managed texture ("managed" is a DirectX term here).

Connection attempt is always initiated on the output pin by passing the interface of the input pin, media type cannot be specified. The output pin enumerates its own supported media types and tries to connect with one after the other until it succeeds.
Inputs cannot change the connection media type upstream, as DirectShow video renderers often did causing a bit of confusion among filter writers.

There is one seeking interface for source filters and there is another for renderers to report the position of the currently presented sample. These two interfaces replace the flags returned by IAMFilterMiscFlags::GetMiscFlags.
Seeking calls do not travel upstream as in DirectShow, filters are freed from implementing the pass-through functions. Routing them was a bit ambigous, too.

BeginFlush and EndFlush were combined into one call with a state parameter, everything else works the same way.

Absent, to prevent the merit raising race.
There is a field called "Auto" in the descriptor which is the same as setting the merit above "do not use" in DirectShow.
The graph manager has events to let the application manipulate the enumerated filters for sources and intelligent connections. Prefered filters can be moved to the beginning of the list, blocked filters removed, anything you think is alright, it will only affect your application.

Protocol, file extension and check bytes * are all considered during the selection and ordering of source filters, the more matches the higher the chance it is used. In DirectShow where filters can register for each separately it is not possible to specify a joined criteria like this one: "file" + ".avi, .divx" + "RIFF....AVI." to raise the priority.
* In reality, filters are asked for the match by giving them an Uri and a Stream, only the baseclasses implement it that way.

Major and subtype is one single guid, the Id field of the media type.
Format guid and format block is reported through different interfaces of the media type object.
Format extensibility is a problem if the type is not one of the predefined types, the connecting filters both have to know about the custom interface. There is an optional byte[] Data property of IMediaType to support basic extensibility, but normally it is there to hold a private codec initalizer data, for example the extra bytes of WAVEFORMATEX. However, if the structure is known, this data could also be reported through the fields of a custom interface for clarity.

The army needs you! And the framework needs more filters to be useful. Please help out if you can.