Kategorien
Elektronik Hard- & Software In eigener Sache Kurzmeldung Medien Projekte

Videotext online: ttxweb im Live-Betrieb bei der ARD

Kurzmeldung

Wie vielleicht einige von euch wissen, faszinieren mich Technik und Geschichte des Teletexts, hierzulande eher bekannt als Videotext, schon seit langem. Die damals wie heute ingenieurstechnisch höchst clevere Mischung aus digitaler Codierung und analoger Fernsehübertragung, insbesondere die Art und Weise, wie das Signal aufgebaut ist und wie einfach es dadurch auf Hardware der damaligen Zeit decodiert werden kann, finde ich bis heute großartig. Auch wenn ich durchaus immer mal wieder meine Zweifel hatte, ob seine schiere Existenz heute noch gerechtfertigt ist, bin ich doch sehr dafür, ihn zu pflegen und gut zu behandeln, solange wir ihn noch haben. ;)

Wie begann sie also, meine „Teletext-Geschichte“? Da meine Großeltern bereits seit den späten 80er-Jahren einen Fernseher mit Videotext-Decoder hatten (im Gegensatz zu meinen Eltern) und ich dort regelmäßig den „Witz des Tages“ (im ARD/ZDF-Videotext auf Tafel 571…) lesen durfte, gehörte dieses Medium für mich von Kindesbeinen an dazu. Wie es genau funktionierte, verstand ich natürlich erst viel später.

Als dann irgendwann Level 2.5-Teletext aufkam und spätere Fernsehgeräte, mit denen ich in der Familie in Berührung kam, tatsächlich diesen Standard unterstützten (Wow! Plötzlich richtige Logos, wie beim ZDF, und eine ungeahnte Farbenvielfalt im Videotext!…), wollte ich irgendwann wirklich wissen, wie das alles funktioniert, und begann, mir im Internet – zum Glück wurde das damals gerade möglich – die entsprechenden Standards zusammenzusuchen und mich einzulesen.

Im Jahr 2011 habe ich mich dann in einem Blogbeitrag und einem zugehörigen, längeren Artikel mit den technischen Hintergründen des Standards beschäftigt und habe versucht, diesen in möglichst verständlichen Worten zu erklären.

Da ich mich in der Folgezeit selbst auch immer mehr mit (Retro-)Hardware beschäftigt habe, wurde mir seitdem mehr und mehr klar, mit welch einfachen Logikbauteilen eine Dekodierung eines Teletext-Signals möglich ist. Wie wenig „State“ ein solcher Decoder hat. Dass es letztlich nur ein paar Bytes RAM, ein paar (Schiebe)register, ein paar Logikbausteine, einen Character Generator mit CG-ROM und ein bisschen Videoelektronik braucht, um einen Teletext-Decoder zu realisieren. Theoretisch alles mit diskreten Bauteilen machbar (bis auf den Seiten-RAM und das CGROM vielleicht).

Irgendwann hatte ich seitdem immer Lust, so etwas selber – komplett diskret – nachzubauen. Allein, es fehlte mir die Zeit und die Muße. Später sah ich dann, dass das schon andere getan haben – in VHDL, was eine großartige Idee ist.

In meinem Beruf ergab sich dann irgendwann die Herausforderung, die Web-Darstellung des hr-texts, des Videotexts des Hessischen Rundfunks, technisch auf neue Beine zu stellen, wenn auch zunächst als vages Ziel, ohne konkreten Auftrag oder Deadline.

Meine Idee, einen eigenen Videotext-Decoder – zumindest Seiten-Decoder, ohne die Empfangs- und Auswahllogik, die ja beim Decodieren von fertigen, als Datei vorliegenden Seiten nicht nötig ist – zu schreiben, in dem Fall mit Ausgabe als HTML, nahm hierdurch neue Gestalt an, und ich programmierte „nebenher“ eine kleine Skriptsammlung in PHP, die genau das tat: ttxweb.

ttxweb kann Videotext-Daten aus einer Datei (momentan im EP1-Dateiformat, eine Anpassung an alle anderen Dateiformate, die Level 1.0/1.5-Teletext-Daten enthalten, ist aber sehr leicht machbar) lesen und in standardkonformes HTML wandeln, das in allen aktuellen Browsern aussieht wie eine „echte“ Teletextseite.

Die Besonderheit – zumindest für mich – daran ist, dass die Dekodierung genauso „stateless“ und ohne separaten „Framebuffer“ für die Displayattribute erfolgt, wie dies ein uralter Teletext-Decoder der allerersten Generation auch getan hätte.

Sprich: die Steuerzeichen werden im Zeitpunkt ihres Auftretens in Anweisungen für die HTML-Ausgabe übersetzt, anstatt dass für jede Zeichenzelle eine Speicherzelle für die Attribute (Vorder-/Hintergrundfarbe, Blinken etc.) vorgehalten würde, wie es z.B. bei einer VGA-Grafikkarte im Textmodus der Fall wäre.

Genau so arbeitet auch ein ursprünglicher Teletext-Decoder ohne Mehr-Seiten-Speicher: letztlich werden die Attribute wie Farbe, Blinken usw. in einfachen Registern vorgehalten und während jeder Rasterzeile während des Auslesens des Seitenspeichers und des CGROM in Echtzeit geändert, sobald im Seitenspeicher an der jeweiligen Spalte ein entsprechendes Steuerzeichen auftritt.

Mit dem Aufkommen von Level 1.5 (erweiterter Zeichensatz) bzw. Level 2.5 (erweiterte Farbpalette und dynamisch definierbare Zeichen) war ein solches Vorgehen dann nicht mehr möglich. Die erweiterten Zeichen bei Level 1.5 werden beispielsweise durch ein zusätzlich übertragenes Packet (X/26), also einer „unsichtbaren“ 26. Zeile, definiert, welche dem Decoder sagt, in welcher Zeile und welcher Spalte er ein Zeichen ersetzen soll. Hier ist definitiv Software nötig, um die entsprechenden Steuer-„Triplets“ zu durchlaufen.

Mein Decoder unterstützt – in auf die in europäischen Sprachen üblichen Sonderzeichen begrenztem Maße – Level 1.5, indem vor der Ausgabe die X/26-Triplets prozessiert und die betreffenden Zeichen durch die korrekten Unicode-HTML-Entitäten ersetzt werden.

Nun – wie ging die Geschichte aus? Ich habe das Ganze Open Source gemacht und auf GitHub gestellt und insbesondere der ARD und allen anderen öffentlich-rechtlichen Rundfunkanstalten ausdrücklich erlaubt, den Code zu verwenden (tatsächlich ist er auch in einem separaten Repository im ARD-internen GitLab eingecheckt, wo noch ein paar Konfigurations-Besonderheiten mitgepflegt werden, die Codebasis ist aber die gleiche). Die Lösung basiert auf zeitgemäßen Webtechnologien, ist mobil-tauglich bzw. responsiv, unterstützt Updates in Echtzeit via XHR, zeigt alle denkbaren Textattribute (inkl. doppelter Höhe/Breite/Größe und Blinken) an, unterstützt, wie gesagt, Level 1.5-Zeichen (auch das „gefürchtete“ @-Zeichen in allen möglichen Codiervarianten) und liest EP1-Dateien sowohl ohne als auch mit X/26-Erweiterungen aus, letztere in mehreren Geschmacksrichtungen (Softel Flair und Softel TAP).

Als erster Sender der ARD nutzt der Hessische Rundfunk nun die Lösung für den hr-text – und spart damit jedes Jahr bares Geld, da nicht mehr auf einen externen Dienstleister für die Web-Darstellung zurückgegriffen werden muss. Das kommt allen Beitragszahlenden zugute. Die neue Lösung läuft auf einem schlanken Webserver (mehr braucht’s ja nicht) als VM in der „ARD-Cloud“ und kann von allen gern hier bewundert werden:

https://hr-text.hr-fernsehen.de

Und ja, ich geb’s zu: ein bisschen stolz bin ich darauf schon… ;-)

Falls irgendwo Interesse an einer Implementierung „in the wild“ bestehen sollte, zögert nicht, mich zu kontaktieren, falls es Fragen zum Deployment geben sollte.

Liebe Grüße und einen guten Rutsch,
Euer Fabian

Kategorien
Elektronik Gesellschaft Hard- & Software Tech Story

Warum Teletext auch 2011 nicht totzukriegen ist…

ARDText (Quelle: Wikipedia)

Hab ich eigentlich schon mal erwähnt, wie absurd die schiere Existenz von Teletext heutzutage ist?

Ursprünglich als Erweiterung des Fernsehsignals um Zusatzinformationen gedacht und in „sowieso nicht genutzten“ Stellen des Videosignals übertragen (nämlich in der vertikalen Austastlücke, auch VBI genannt), gibt es heute in der gesamten Signalkette zwischen der Person, die den Teletext redaktionell und technisch erstellt und derjenigen, die sie zu Hause am Fernseher konsumiert, praktisch keine Stelle mehr, an der er wirklich in der vertikalen Austastlücke irgendeines Videosignals (und somit quasi „nebenher“, ohne zusätzlichen Aufwand) transportiert würde!

Ja! (Keine Angst, es folgt jetzt kein grundsätzliches Plädoyer gegen Teletext oder so…)

In den Sendeanstalten ist es seit der Umstellung auf HDTV und damit der flächendeckenden Verwendung sogenannter HD-SDI-Signale im Funkhaus gar nicht mehr (standardkonform) möglich, Teletextsignale oder überhaupt „Datenzeilen“ im klassischen Sinne in das Videosignal zu insertieren, schlicht weil es dafür keinen Standard gibt. Nicht, dass es nicht möglich wäre („Bits übrig“ sind massig im HD-SDI-Signal und für alle möglichen Arten von Timecode, Ton, Beschreibung des Bildformates etc. gibt’s auch Standards, wo im Signal man die nun unterzubringen habe – nur für klassische SD-VBI-Daten noch nicht). Also wird in den Sendern der Teletext per Netzwerk (jawohl!) übertragen, oder, noch schlimmer: alleine für diesen Zweck existiert ganz einfach noch eine analoge SD-Videostrippe die „nebenher“ läuft und nur die Zeilen der Austastlücke quasi „zum Sendemast“ transportiert. Da gehts dann nämlich erst richtig los:

Auf dem digitalen Übertragungsweg (DVB-S/S2, DVB-T/T2, DVB-C/C2) gibt es nämlich schon lange vor HDTV, seit mindestens 10 Jahren, keine vertikale Austastlücke mehr. Stattdessen müssen die Daten, die dort zu analogen Zeiten übertragen worden wären, umständlich in digitale Datenpakete „umverpackt“ und als extra Datenstrom mit eigener „PID“ (Program ID) gesendet werden.

Und schlussendlich gibt es, seit sich HDMI als Verbindung zwischen Receiver und Fernseher gegenüber SCART durchgesetzt hat, auch gar keine Möglichkeit mehr, die Teletextdaten an den Fernseher zu übertragen, schlicht weil es in HDMI ebenfalls keine „Austastlücke“ mehr gibt!

Sprich: Der Receiver selbst muss den Teletext dekodieren und quasi „als Bild“ anzeigen, was dann auf dem Fernseher sichtbar wird.

An der ganzen Kette ist also praktisch nichts mehr so wie früher, es ist ein wildes Hin- und Her-Ge-„wrappe“ von Datenströmen, um immer der jeweils nächsten „Schicht“ die „alten Verhältnisse“ vorgaukeln zu können (JA, klar: es ist möglich – und viele Receiver machen das auch – , aus dem ganzen Teletext-Strom wiederum – ja, jetzt wird’s traurig – analoge Daten-Videozeilen zu generieren, die dann am SCART-Ausgang wieder in die Austastlücke eingetastet werden). Damit Omas Röhrenfernseher mit Teletextdekoder alles so vorfindet, wie vor 30 Jahren…). OK, ganz so dumm ist die Sache mit der Kompatibilität ja auch gar nicht – wird ja auch anderswo gemacht, schließlich ist so ein Videosignal auch heute noch zu Schwarz-Weiß-Fernsehern kompatibel

Auf der anderen Seite hatten es Nachfolgeangebote wie MHP, DigiText, intercast, Zap2Web und wie sie alle hießen, nie eine Chance sich durchzusetzen. Und das, obwohl sie grafisch und technisch viel ansprechender sind, als der Teletext, den damals die BBC im Jahre 1976 erfunden hat und der heute ja im Prinzip noch genau so aussieht.

Ich frage mich: Warum? Auch so, wie es jetzt ist, ist eigentlich nichts mehr „wie es war“ und über all die Jahre wurde mannigfaltig neuimplementiert (z.B. Routinen, um aus analogen Teletextzeilen die Daten für die DVB-PID zu machen; Routinen, um das ganze wieder aus einem DVB-Multiplex rauszuextrahieren, zu dekodieren und als Bild zu „zeichnen“, damit man es am ultramodernen Flachbildfernseher über HDMI auch ansehen kann).

Keine Angst, das hier soll – immer noch – kein Plädoyer gegen den guten (?) alten (!) Teletext sein, er hat sicher seine Berechtigung, zumindest gehabt. Dennoch: wir haben heute überall und immer Internetzugang. Wäre es nicht sinnvoller, auf das ganze Teletext-Geraffel ein für alle mal zu verzichten, spätestens jetzt, wo fast alle neuen Fernseher sowieso einen LAN-Anschluss haben?

Oder, wenn man denn unbedingt mit dem Fernsehsignal Zusatzdaten übertragen will: Doch mal umzustellen auf was HTML-basiertes an Stelle des antiquierten 40-Zeichen-24-Zeilen-Bildschirmtext-Standards (CEPT)? Wenn ja doch – ich wiederhole mich wieder – sowieso an keiner Stelle der Signalkette mehr der Teletext so übertragen wird wie früher, also im Videosignal „inhärent“ und ohne dabei Aufwand zu verursachen?

Stattdessen dieser Tage extra LAN-Infrastrukturen in den Sendern geschaffen werden müssen, nur um die paar Bits/s zum Sendemast transportieren zu können…

Es kostet den Gebührenzahler eigentlich „unnötig“ Geld, wenn die Anstalten – nur für diesen Service! – beim HD-Umstieg ganzer Sendeabwicklungen allerlei technische Klimmzüge machen müssen, nur um auch im Jahre 2011 noch Klötzchengrafik in die Wohnzimmer bringen zu können! (Ich mag sie trotzdem, die alte Klötzchengrafik, ja…)

Wie auch immer, ich schätze wohl, dass jegliche Elaboration gegen Teletext (was das hier wirklich nicht sein soll!) bei eingefleischten Teletext-Fans ohnehin auf Granit stoßen wird: Die würden auch wenn nur für Teletext eine DSL-Leitung zusätzlich zum HD-Sat-Receiver ins Haus gelegt werden müsste, nicht drauf verzichten wollen. Und dann den Web-Teletext auf www.tagesschau.de oder www.zdf.de aufrufen…

Daher: keine Sorge, den Teletext wirds wohl (zum Glück oder leider?) auch in 10 Jahren noch geben. Mindestens.

[Update: Für alle, die auch die Bits & Bytes „hinter“ Teletext verstehen möchten, habe ich ein paar Details zu den technischen Hintergründen von Teletext zusammengetragen, und zwar im Artikel „Teletext wirklich verstehen“, der ab sofort im Bereich „Texte“ zu finden ist.]