Im Rahmen von DVB.NET 3.1 möchte ich in einen DirectShow (COM basiert) Filtergraphen eine .NET Klasse einbinden. Die Klasse klemmt sich in den Datenstrom zwischen einen TS Capture Filter und einen Demultiplexer – nicht wirklich ein Problem. Auf der Eingangsseite (Input Pin) der .NET Klasse werden über eine COM Schnittstelle IMemInputPin so genannte Media Samples (IMediaSample) entgegengenommen. Die Klasse macht damit was und gibt sie dann unverändert an die gleichartige Schnittstelle des Demultiplexers an der Ausgangsseite (Output Pin) weiter. Es kommt ein Fehler 0x80040155 (REGDB_E_IIDNOTREG)!
Dieser Fehler ist ein COM Marshalling Fehler. Er bedeutet, dass COM versucht hat, eine Schnittstelle aus einem Apartment in ein anderes zu transferieren, dabei aber keinen Eintrag in der Registery (HKCR\Interface) für die Schnittstelle gefunden hat und die betroffenen COM Klasse auch kein Custom Marshalling anbietet (IMarshal).
Nun gut, was könnte also hier passieren? Der Filtergraph wird im Hauptprogramm, einer Windows Form, angelegt, damit auch alle Filter (COM Komponenten). Der Natur der Sache nach wird dazu ein Single-Threaded-Apartment (STA) verwendet. Durch die Gegebenheiten in einem DirectShow Graphen muss ich allerdings die Weitergabe der Media Samples auf einem eigene Thread machen (sonst blockiert der Graph). Das kann natürlich nie dasselbe Apartment sein, wie das Heimatapartment der Komponenten.
Nun, wie macht Microsoft das? Ein Blick in das DirectShow SDK zeigt, dass in Graphen COM Regeln wohl etwas lockerer gesehen werden. Das Infinite Tee Beispiel von Microsoft nimmt COM Schnittstellen wie sie kommen und nutzt sie ohne eine Marshalling gnadenlos auf einem anderen Thread. Nun gut, machen wir das mit .NET. Geht aber nicht (so einfach)!
Der erste Versuch, die .NET Schnittstelle einfach im anderen Thread zu verwenden, hatten wir oben schon. Auch der Trick, im STA ein Marshal.QueryInterface zu machen, fruchtet nicht. Man erhält hier tatsächlich eine IntPtr auf die COM Schnittstelle zum direkten Zugriff. Packt man diese in dem Worker Thread aber via Marshal.GetObjectFor IUnknown aus, ist .NET wieder so clever, ein Marshalling anzustossen. Böse Falle.
Ok, es geht doch, aber was jetzt kommt ist zumindest verboten 🙂 Also mit Vorsicht geniessen! Das ganz fängt mit folgendem Code Fragment an (da gab es einige Zwischenschritte bis zu genau dieser Lösung, die es tut – Details erspare ich hier mal):
private delegate void MediaSampleSink(IntPtr classPointer, IntPtr[] sampleArray, Int32 sampleCount, out Int32 processed);
private MediaSampleSink m_MemSink = null;
private IntPtr m_MemPin = IntPtr.Zero;
m_MemPin = Marshal.GetComInterfaceForObject(m_Connected, typeof(Interfaces.IMemInputPin));
IntPtr comFunctionTable = Marshal.ReadIntPtr(m_MemPin);
IntPtr receiveMultiple = Marshal.ReadIntPtr(comFunctionTable, 28);
m_MemSink = (MediaSampleSink)Marshal.GetDelegateForFunctionPointer(receiveMultiple, typeof(MediaSampleSink));
Aus der Eingangsadresse des anderen Filters (m_Connected ist der IMemInputPin) wird die COM Schnittstelle ermittelt. Dann relativ trivial die Adresse der Funktionentablle und schließlich die Adresse der 7ten Methode (IMemInputPin:ReceiveMultiple). Der erstellte Delegate berücksichtig dabei, dass bei einem COM Aufruf der zusätzliche, normalerweise unsichtbare, erste Parameter die Adresse des COM Objektes ist.
Nun funktioniert folgender Aufruf wie gewünscht:
IntPtr[] toProcess = ...;
Int32 processed;
m_MemSink(m_MemPin, toProcess, toProcess.Length, out processed);
Wie gesagt: eigentlich werden hier COM Regeln auf das übelste verletzt. Es fragt sich allerdings, ob in einem DirectShow Graphen nicht wirklich andere Regeln gelten, bei denen COM Schnittstellen nur zur Zerlegung in Komponenten verwendet werden, Apartments aber keine Rolle spielen. Müßte ich mal recherchieren – ich hoffe im Moment einfach mal, dass es so ist (zudem alle Microsoft DirectShow Beispiele es auch so handhaben).
Immerhin, ein kleiner Schritt in Richtung DVB.NET 3.1!
Viel Spaß
Jochen
