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

Neues Format der Senderliste für Sender mit mehr als einer AC3 Tonspur

Nach einer eleganten Lösung habe ich mich jetzt für eine kompatible Lösung entschieden. Damit können mit der DVB.NET 3.1 Beta erstellte Senderlisten von VCR.NET 3.0 verarbeitet werden. Dieser sieht allerdings nur die erste AC3 Tonspur. Damit dies möglich ist, wurde das Format der Senderliste erst mal identisch gehalten. Für jede MP2 Tonspur gibt es ein <AudioInfo> Tag mit eindeutigem Namen (zusammengesetzt aus Sprache und PID) und PID. Die primäre MP2 Tonspur (die gemäß der Information von der Sendeanstalt im Suchlauf als erste angeboten wurde) wird zusätzlich im <Audio>Tag vermerkt (der Wert kann 0 sein, wenn der Sender keine MP2 Tonspur anbietet). Im <AC3> Tag findet sich völlig äquivalent die primäre AC3 Tonspur.

Neu sind <AC3Info> Tags, die völlig analog zu den <AudioInfo> Tags die AC3 Tonspuren beschreiben. Zwischen Sprache und PID wurde ein (AC3) zusätzlich eingefügt, so dass eine spätere Auswahl eindeutig zugeordnet werden kann (Deutsch [3073] vs. Deutsch (AC3) [3075]). Liest eine Pre-3.1 DVB.NET Anwendung eine solche Datei, werden die AC3 Informationen einfach ignoriert – beim Schreiben der Senderliste würden sie unwiederbringlich verloren gehen, also Vorsicht!

Übrigends: die <AudioInfo> und <AC3Info> Tags sind nicht sortiert und die Reihenfolge der einzelnen Tonspuren einer Gruppe mehr oder weniger willkürlich.

Sowohl die DVB.NET 3.1 Recording Tools als auch der VCR.NET 3.1 Recording Service werden auch mit dem alten Format klarkommen. Es sind dann halt außer dem PID der primären AC3 Tonspur keine Informationen vorhanden. Es ist noch unklar, in welchem Umfang die Informationen in den DVB.NET 3.1 Werkzeugen genutzt werden. Sicher werden die Quick Records alle Tonspuren aufzeichnen, die sie finden. Ob aber eine gezielte Auswahl einer Spur möglich ist, weiß ich noch nicht.

Jochen