Strong Name Assemblies in DVB.NET – Ursache und Wirkung

Ich habe mich trotz einiger Folgeprobleme (siehe gleich) entschieden, endlich mal die Assemblies und Anwendungen der DVB.NET / VCR.NET Pakete mit einem Strong Name zu versehen (Ausnahme: Quick Record (VLC) und Zapping Client, da war ich zu faul, die ActiveX Wrapper für VLC neu zu erstellen). Das hat den Effekt, dass man nun (ab 3.1) eine Assembly als die ‚Originalversion‘ aus dem DVB.NET (et al) Paket erkennen kann. Wenn es also irgendwann mal Anwendungen von anderen Entwicklern geben sollte, die DVB.NET verwenden, so läßt sich bei Problemen schnell feststellen, ob es an DVB.NET oder einer ‚modded‘ Variante liegt.

Natürlich wird der gesamte Quellcode weiterhin mitgeliefert. Wenn jemand DVB.NET in eigenen Anwendungen Out-Of-The-Box (mit der Option des Supports, soweit es in meinem Möglichkeiten steht) verwendet, muss er nur (jetzt und mit jeder neuen Version) die Referenzen erneuern – so kann dann auch gezielt eine DVB.NET Version angesprochen werden. Lediglich wenn man DVB.NET selbst übersetzen und verändern möchte, muss man sich ein eigenes Schlüsselpaar erzeugen (ich hoffe, dass ich das über relative Referenzen einfach genug gemacht habe – das Schlüsselpaar selbst gibt es via sn -k dvbnet.snk). Damit sind dann auch so erstellte Assemblies und Anwendungen als Varianten des originalen DVB.NET erkennbar – das ist ja auch der Sinn der Aktion.

Ich gebe allerdings zu, dass ich ein schwerwiegendes Problem mit der Installation von VCR.NET habe. Ich werde dem noch nachgehen müssen, aber es scheint, als käme eine Upgradeinstallation mit den Assemblyversionen durcheinander. Ich habe da zwar etwas im Test, weiß aber noch nicht, ob das Problem damit gelöst ist. Sicher geht der eh empfohlene Weg, vor jeder VCR.NET Installation die Vorgängerversion explizit zu deinstallieren.

In der Hoffnung, nicht allzu viele Mühen verursacht zu haben

Jochen

Multimedia Streaming: kleine Schritte vs. die große Lösung

Praktisch mit der Einführung von Aufzeichnungen als Transport Stream Dateien hat DVB.NET und damit auch VCR.NET die Möglichkeit erhalten, die aufgezeichneten Daten so, wie sie auf Platte geschrieben werden, auch über Netzwerk zu versenden. Dabei wird der Versand einmalig aktiviert und der Datenstrom an einen TCP/IP UDP Endpunkt geleitet. Erst nur an einen Client (Unicast), später dann durch die Verwendung von Multicast auch gleichzeitig durch mehrere Clients zu empfangen.

Dieser Ansatz hat allerdings den Nachteil, dass immer nur die gerade laufende Aufzeichnung (so zu sagen das Ende der aktuellen Aufzeichnung) betrachtet werden kann. Und es müssen auch immer alle Clients genau das selbe ansschauen.

Bei VCR.NET 3.0 habe ich versucht, im Web Client durch Einsatz des VLC ActiveX Controls eine Möglichkeit zu schaffen, dass auch mehrere Clients individuell in eine Aufzeichnungen schauen können. Durch den Einsatz von HTTP als Basis ist es dabei auch nicht notwendig, besondere Maßnahmen bei der Konfiguration der Firewalls zwischen Server und Client vorzusehen. Allerdings hat auch dieser Ansatz eine Reihe von Nachteilen. Neben der Instabilität und Einschränkungen des Controls und Problemen bei der Bedienung des Timeshifts ist das TCP basierte HTTP Protokol ein wesentlicher Schwachpunkt.

Der realisierte Ansatz erfordert, anders als das UDP Streaming, eine bidirektionale Kommunikation zwischen Client und Server. Im Endeffekt werden in gewissen Abständen die Datenpakete des Servers (der Transport Stream) vom Client bestätigt. Dadurch kann gerade bei hochratigen Aufzeichnungen kein permanenter und gleichmäßiger Datenstrom garantiert werden und es kommt zu Rucklern.

Nun, das ist nichts Neues. Es gibt auf vernünftige, aber aufwändige Lösungen für dieses Problem (RTP, ASF, …). Eine Implentierung für VCR.NET 3.1 ist für mich allerdings zeitlich nicht zu machen (vermutlich nicht einmal die Evaluation) – für die 3.1er Generation stehen andere Punkte im Vordergrund. Darum wird es einen kleinen Schritt geben, der allerdings mit einem dedizierten Client (dem DVB.NET / VCR.NET Viewer) schon den gewünschten Effekt bringen kann.

Bei Live Betrachtungen (des Endes einer Aufzeichnung, i.e. das, was gerade zur Platte geschickt wird), wird das UDP Streaming die bevorzugte Methode sein. Eine Konfiguration der Firewall(s) sollte in diesem Rahmen machbar sein. Interessanter wird es beim Timeshift (und darüber hinaus, dazu gleich mehr). VCR.NET 3.1 wird voraussichtlich eine (SOAP) Methode haben, um aus einer Aufzeichnungsdatei ein beliebiges Stück (Offset / Länge – bis maximal 10 MByte) an eine beliebige UDP (Unicast oder Multicast) Adresse zu senden. Zusammen mit dem neuen BDAWindow Control in DVB.NET 3.1 wird dann nach Bedarf ein Stückchen Transport Stream angefordert. Dieser Bedarf wird durch die Überwachung der Zeitstempel im Direct Show Graphen ermittelt und hat sich schon beim Abspielen von Dateien bewährt. Der Graph wird dabei mit Vorlaufmaterial beschickt, bis dessen Zeitstempel mehr als eine Sekunde in der Zukunft liegt (bezogen auf das zuletzt dargestellte Bild oder Tonsignal). Durch diese Pufferung sollte eine nahtlose Darstellung möglich sein – wie gesagt, bei Dateien funktioniert es wie gehofft. Das Bewegen in der Aufzeichnungsdatei ist mit diesem Mechanismus ebenfalls kein Thema.

Die SOAP Schnittstelle ist darüber hinaus darauf vorbereitet, jede Aufzeichnungsdatei auf diesem Wege abrufen zu können. Eine Aufzeichnungsdatei ist dabei eine beliebige Datei mit der Endung .TS, die in einem der VCR.NET Aufzeichnungsverzeichnisse (oder darunter) zu finden ist. Vielleicht erlaubt es VCR.NET 3.2 dann auch, ältere Aufzeichnungen einfach abzuspielen.

Soweit für heute. Wenn das alles wie gewünscht klappt, werde ich mir danach anschauen, welche Art der Zusammenarbeit es zwischen dem DVB.NET / VCR.NET Viewer und FFDShow und DScaler geben kann.

Jochen

Rückschläge, Lichtblicke und kleine Erfolge

Wie schon gesagt war der DVB.NET Viewer das Thema der letzten Wochen. Die ursprüngliche Idee war, einen DVB.NET / VCR.NET Transport Stream (TS) in einen Direct Show Graphen einzuspeisen. Dazu dient ein spezieller (In-Memory) Filter namens TSFilter (natürlich in .NET), der eingehende Daten an einen Microsoft MPEG-2 Demultiplexer weiterleitet. An diesen angeschlossen werden dann zwei Stränge für Bild und Ton und das sollte es tun. Dachte ich, ist aber nicht ganz so einfach. Ich denke, einen guten Anteil an den Rucklern des ersten DVB.NET Viewer Previews hat genau dieser Demultiplexer (naja, einiges geht auch auf mein Konto via DVB.NET). Auch den leicht versetzten Ton buche ich im Moment auf diesen Filter. Was aber das Ganze unbrauchbar macht ist, dass der Filter, wie der Name schon sagt, mit einem MPEG-4 Teilstrom selbst als MPEG-2 PES gekapselt nicht wirklich etwas anfangen kann. Entweder ich habe den falsch konfiguriert (sicher nicht auszuschliessen) oder am Ausgang eines HDTV Pins kommt wirklich nichts.

Nun dachte ich mir, es kann doch nicht so schwer sein, den TS Strom selbst zu zerlegen und direkt Bild und Ton in den Graphen zu füttern. Und tatsächlich ist alles dazu in DVB.NET schon drin – einige kleiner Erweiterungen erlauben auch die Nutzung teilweise verborgener Methoden, aber das ist nur Makulatur. Nach einigen Abenden Versuchen hätte ich es dann fast aufgegeben. Bild alleine war kein Problem, aber irgendwie langweilig und ruckelig. Den Ton mit einem File Writer in eine Datei zu schreiben gab eine einwandfreie ES sprich MP2 Datei. Nur den Ton in den Graphen genau so einspeisen ging nicht: ein übler Fehler tief im Graphen nach wenigen Sekunden verursachte einen Absturz des Viewers.

Nach einiger Recherche schien es mir dann so, dass das Geheimnis wäre, aus dem TSFilter eine Direct Show Live Source zu machen. Das ist, folgt man der Beschreibung, etwas mühsam und war nicht wirklich von Erfolg gekrönt. Kurz vor dem erneuten Aufgeben heute hatte ich Bild und Ton mit kurzen Stoppern, allerdings eilte das Bild dem Ton trotz einiger Versuche, das Timinig in den Griff zu bekommen, um gute 5 Sekunden hinterher. Nicht wirklich nutzbar!

Dann habe ich den gesamten (!) Live Source Code wieder entfernt und nur zwei Direct Show Schnittstellen dringelassen, die aber dem Graphen eindeutig sagen, dass der Filter keine Direct Show Live Source ist. Und… nun scheint alles zu gehen! Bild und Ton sind synchron, auch bei MPEG-4 HDTV und AC3, Radio geht auch (mit einigen Einschränkungen in der Bedienung – im Moment noch nicht Thema). Es scheint tatsächlich so zu sein, dass man diese Schnittstellen anbieten muss und beim Füttern von Bild- und Tondatenstrom in den Graphen nur die Zeitstempel (PTS umgerechnet in Stream Times) richtig setzen muss. Im Moment wird der Ton als Bezugsbasis (0-Zeit im Graphen) genommen und nur der Tonstrom als Synchronisationsbasis gekennzeichnet.

HDTV AC3 Radio

Vorbehaltlich weiterer Untersuchungen wären dann alle Evaluationen für DVB.NET / VCR.NET 3.1 abgeschlossen. Der Rest ist dann mehr oder weniger Fleißarbeit – und das nicht zu knapp. Hier nun die unmittelbar nächsten Schritte, was den DVB.NET Viewer und die DVB.NET BDA Technologie betrifft. Ein neues Preview des Viewers mit HDTV und AC3 Unterstützung kann es erst geben, wenn einige Basisfunktionalitäten (wieder) hergestellt sind.

  • Ich habe bisher nur mit der lokalen (DVB.NET) Variante des Viewers experimentiert. Hier muss ich den aktuellen Codestand klarziehen und die Änderungen in DVB.NET verankern. Kritisch ist, dass dabei auch der Teil der BDA Implementierung angefasst wurde, der mit der Anzeige nichts zu tun hat (DVB Karten via BDA). Hier muss ich sehr sorgfältig sicherstellen, das ich nichts kaputt gemacht habe.
  • Dann kommt die VCR.NET Anbindung (Zapping / Live respektive Watch Mode) dran. Hier werde ich in der ersten Phase nur eine Anpassung an VCR.NET 3.1 machen (vor allem zur Unterstützung von mehr als einer AC3 Tonspur). Dann kann es sein, dass ich ein zweites DVB.NET Viewer Preview mache – ich brauche bald Unterstützung von den Beta-Testern um zu sehen, mit welchen Direct Show Filtern das überhaupt läuft und wie es um die verschiedenen HDTV und AC3 Varianten steht. Danach muss ich die gesamte SOAP Anbindung des Viewers überarbeiten. Diese ist synchron und sicher für den einen oder anderen Ruckler verantwortlich.
  • Schließlich wäre die nächste DVB.NET 3.1 Beta an der Reihe. Wichtig ist die Umsetzung der gewonnenen Erkenntnis im BDA Umfeld für den Quick Record (Standard Edition). Da will ich aber nicht zu viel versprechen, denn am liebsten würde ich beide Quick Records zugunsten des DVB.NET Viewers in der aktuellen Version einfrieren. Die sollte es dann aber immerhin noch tun!
  • Zur Abrundung dann auch eine neue VCR.NET 3.1 Beta, die aber im Wesentlichen die funktionalen Veränderungen adaptiert und keine neuen Funktionalitäten enthalten wird.

So wie es jetzt aussieht, werde ich dann wohl mit der Abarbeitung der VCR.NET 3.1 Wunsch- und Fehlerliste angehen. Vielleicht so 2 bis 4 größere Punkte bis zur übernächsten Beta, dann wieder DVB.NET, Viewer usw. Es könnte sein, dass die 3.1er Generation dann im Frühherbst freigegeben werden kann – aber wer weiß, was so alles dazwischen kommt (im Moment ist die Freizeit knapp und meine Produktivität nach 23:00 reicht gerade mal für Posts wie diesen).

Viel Spaß

Jochen

Next Stop: DVB.NET Viewer

Puh, das war eine Menge Fleißarbeit, die VCR.NET ASP.NET Web Anwendung auf Master Pages und Themes umzustellen. Funktional ist nur wenig hinzugekommen, wobei sich dieses wenige aber als recht nützlich erweist (ein paar Verweise an den richtigen Stellen wirken Wunder). Als Beispiel habe ich ergänzend zum bekannten VCR.NET Theme (den habe ich mal Classic genannt) eine Konfiguration entworfen, die in etwa den Stil der VCR.NET Homepage wiedergibt.

Damit ist das Thema vorerst (sprich Evaluation) abgeschlossen. Nun geht es an den DVB.NET Viewer. Zuerst einmal rein technische Fleißarbeit bei der Anbindung an einen VCR.NET Recording Service (synchrone Aufrufe, die vielleicht die Darstellung stören und schwere Abbrüche bei SOAP Kommunikationsfehlern sind das Hauptthema). Dann möchte ich in der nächsten Evaluationphase versuchen, den DVB.NET Viewer soweit zu bekommen, dass er auch Radio, AC3 und MPEG-4 abspielen kann (von links nach rechts bin ich immer skeptischer, ob ich das in der mir zur Verfügung stehenden Zeit hinbekomme). Danach geht es mit VCR.NET weiter, wo eine ganze Reihe Betriebsfeatures auf die Realisierung warten.

Schau’n mer mal

Jochen

EPG et al – ein kurzer Statusbericht

Ich habe mich nun ein wenig mit dem SkyEPG auseinandergesetzt, der properitären Programmzeitschrift der englischen Sender auf Astra 2 (28° Ost) – BBC, ITV und Konsorten. Die Informationen dazu sind mager und es sieht nicht so aus, als würde ich in absehbarer Zeit (sprich bis zu DVB.NET 3.1) ein ausreichendes Verständnis für eine Unterstützung entwickeln – tatsächlich weiß ich heute noch nicht einmal, ob eine Nutzung ohne Abo überhaupt möglich ist i.e. ob das SkyEPG verschlüsselt ist oder einfach nur in einem properitären Format vorliegt. Wie dem auch sei: mein Zeitpensum für die Voruntersuchungen ist erschöpft und ich habe das Thema für die 3.1er Versionen erst einmal ausgeklammert.

Für das konventionelle EPG gibt es aber einige zusätzliche Unterstützung. In den Transport Stream Generator von DVB.NET wurde die Möglichkeit eingebaut, EPG Informationen in die TS Dateien mit einfliessen zu lassen. Das bereits bekannte Werkzeug EPG Reader ist nun Teil von DVB.NET und kann verwendet werden, um diese Informationen zu extrahieren – mittelfristig ist allerdings der Hauptfokus der DVB.NET Viewer. Auch VCR.NET wird die EPG Informationen des Senders einer TS Datei immer mit einmischen – für Nexus / TechnoTrend Premium Anwender bedeutet das keine Einschränkung bezüglich der nutzbaren Datenströme, deren Anzahl weiterhin bei 8 liegt [DVB SI Tabellenfilter sind zwar auch beschränkt, aber unabhängig von PES Filtern]. Bei dem Einspielen in die TS Datei werden einige Informationen im EPG so verändert, dass alle Daten als zum TS Inhalt gehörig erkannt werden – das betrifft etwa die Dienstkennung des aufgezeichneten Senders. Spielt man eine solche Datei mit VLC ab, so kann man in den erweiterten Medieninformationen den Titel der gerade laufenden Sendung anschauen – das soll der DVB.NET Viewer dann auch können. In der nächsten Beta Version wird in DVB.NET nur der Stream Manager EPG Informationen in TS Dateien einmischen können, nicht aber die beiden Quick Records.

Das ist mein lokaler Stand jetzt und nun geht es zum nächsten Schritt in Richtung 3.1. Als erstes werde ich mir bei VCR.NET im Web Client die Möglichkeiten anschauen, die eine einfache Trennung der Oberfläche von der Anwendungslogik erlauben – ich meine hier Themes, Skins und anderes, das ich wie diese auch nur dem Namen nach kenne, sowie eine mögliche Personalisierung durch den Administrator oder gar den Anwender selbst. Da ist für mich ein großes weißes Blatt und ich bin mal gespannt, was es zu lernen gibt. Ich hoffe, dass die nächste VCR.NET 3.1 Beta davon schon etwas enthält – die aktuelle Beta ist primär wegen der Erweiterung auf mehrere AC3 Tonspuren entstanden.

Ohne allzu weit in die Zukunft zu schauen ist danach wieder das Thema DVB.NET Viewer dran. Allerdings immer noch nicht die ordentliche Synchronisation des Graphen als Ganzes, sondern die Nutzung anderen Datenströme als MP2 (AC3) und MPEG-2 (MPEG-4) sowie die Unterstützung von Radiosendern. Auch hier gibt es einiges im Bereich DirectShow zu lernen…

Dazu kommt noch die Implementierung des Zugriffs auf VCR.NET im Zapping (LIVE) oder Watch Modus – die SOAP Kommunikation ist noch synchron (das könnte eine Ursache für Störungen in der Wiedergabe sein) und enthält keine ordentliche Fehlerbehandlung.

Weiter will ich heute noch nicht planen, für die Zeit, die ich für DVB.NET und VCR.NET zur Verfügung habe, ist das schon eine ganze Menge.

Viel Spaß

Jochen