Dr. Jochen Manns

Für den Sendersuchlauf hatte ich mir einige Dinge zur Nachbearbeitung überlegt, die ich aber nur zum Teil bereits in DVB.NET / VCR.NET 3.1 realisieren werde – den Rest spare ich mir dann für die oder eine der nächsten Versionen auf, damit es bald mal wieder einen Release Stand gibt. Ich hoffe aber, dass die vorhandene Implementierung eine gute Basis darstellen und für die wichtigsten Probleme eine ausreichende Lösung bietet.

Die Grundidee war, dass nach einem Sendersuchlauf die neue Senderliste nicht nur einfach das Ergebnis des Suchlaufs ist, sondern eine bereits modifizierte Senderliste adaptieren kann. Bereits mit der aktuellen Version 3.0 gab es einen so genannten Aktualisierungsmodus, der aber nur dafür sorgte, dass Sender, die nur zeitweise empfangen wurden, nicht verloren gehen. So sendet etwa BBC THREE tagsüber nicht, die dann freien Datenströme (PID) für Bild und Ton werden vom Kinderkanal CBBC genutzt, der seinerseits nichts nachts sendet. Ein Suchlauf tagsüber und einer Nachts liefert (diesbezüglich) eine vollständige Senderliste.

Die Implementierung in den 3.1er Versionen wird diesen Mechanismus erweitern. Sie wird allerdings nicht die (bereits vorgesehene) Möglichkeit bieten, Sender aus dem Sendersuchlauf auszublenden, etwa alle verschlüsselten Sender. Damit könnte zum Beispiel die Senderliste (bei mir etwa 2 MB für Astra 1 und Astra 2) deutlich im Umfang reduziert werden. Im Zusammenspiel mit VCR.NET sind allerdings keine unmittelbaren Vorteile zu erwarten, da der Web Client ja bereits einige Filtermöglichkeiten bietet, mit denen die Senderliste zur Auswahl reduziert werden kann. Auch die Konfiguration der Nachbearbeitung (dazu werde ich hoffentlich in Kürze mit der Freigabe der nächsten Beta von DVB.NET 3.1 eine kurze Dokumentation auf der DVB.NET Homepage anbieten können) ist noch wesentlich rudimentärer, als ich es mir gewünscht habe.

Aber mal schauen, vielleicht reicht es für den täglichen Gebrauch ja – richtig lästig ist im Moment nur eine vollständige Aktualisierung der Senderliste, aber das soll hier nicht Thema sein. Vielmehr am Ende kurz einige Beispiele, von dem, was bei mir hier lokal schon möglich ist.

Die Konfiguration arbeitet immer auf einer vorhandenen Senderliste. Man kann für jeden Sender individuell einstellen, welche Detaildaten nach einem Sendersuchlauf erhalten bleiben sollen. Der gesamte Mechanismus greift grundsätzlich nur im erwähnten Aktualisierungsmodus. Wird der Sender gar nicht gefunden, bleibt alles wie gehabt. Wird er gefunden, so würde er in der Version 3.0 gänzlich durch die neu gefundenen Daten ersetzt. Mit dem neuen Mechanismus kann man nun:

• etwa für KiKa den VideoText PID, der nur tagsüber verwendet wird, fixieren
• etwa für KiKa den PID und die Sprache der Tonspur fixieren (die Sprache ist nachts undefiniert)
• etwa für PREMIERE sicherstellen, dass immer beide Tonspuren vorhanden sind
• die Sprache einer Tonspur festlegen, wenn diese in den SI Tabellen ‘falsch’ gemeldet wird
• den Namen eines Sender ändern und fixieren

Naja, so viel mehr Detailinformationen zu einem Sender verwaltet DVB.NET (noch?) nicht. Zusätzlich wird es möglich sein, einen Sender als Regionalsender (konkret: mit variablen PIDs) zu kennzeichnen. Zumindet VCR.NET 3.1 soll die Fähigkeit erhalten, eine solche Veränderung zu erkennen und die Aufzeichnung entsprechend mit zu fahren. Mal schauen…

So, dass soll erst mal reichen

Jochen

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

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.

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