Digitales VPS

VPS (Video Programming System) ermöglicht vollständige und genaue Aufnahmen von Sendungen, auch wenn es im Programmablauf zu Verschiebungen der Startzeit und Überziehungen kommt. VPS ist eine Entwicklung von ARD/ZDF und wird seit der IFA 1985 von ARD und ZDF regulär ausgestrahlt.

VPS basiert darauf, dass der Sender die VPS-Zeit einer Sendung überträgt, solange wie die Sendung läuft. Diese dient als eindeutige Identifikationsnummer (Label) dieser Sendung und ist in der Regel die (ursprünglich) angekündigte Startzeit der Sendung. Diese VPS-Zeit muss im Videorekorder bei aktiviertem VPS als Startzeit angegeben werden. Der Videorekorder schaltet rechtzeitig vor der geplanten Zeit auf den Sender, wartet bis das Label (die eingegebene VPS-Zeit) übertragen wird und beginnt mit der Aufnahme. Wenn das Ende bzw. eine andere Sendung signalisiert wird, stoppt die Aufnahme. Pausen (z. B. Werbung oder andere Sendungsunterbrechungen wie bspw. Nachrichten) können ebenfalls signalisiert werden.

Im digitalen Fernsehen sind diese und weitere Mechanismen ebenfalls möglich. Anders als beim ursprünglichen analogen VPS bzw. PDC (Programme Delivery Control) gibt es allerdings keine einzelne, konkrete Spezifikation mehr die die Möglichkeiten und die Implementierung gesammelt beschreibt. Vielmehr ergänzen die neuen Standards für DVB-Fernsehen und den Transport von digitalen SD- und HD-Signalen die ursprünglichen Verfahren um weitere Möglichkeiten und Übertragungsmethoden. Die Abhängigkeiten und Verweise von neuen Standards zu teilweise bereits mehrere Jahrzehnte alten Dokumenten machen es aber für jüngere Entwickler und Ingenieure schwer einen vollumfänglichen Überblick über die Thematik zu erhalten. Insbesondere wenn dabei analoge Verfahren beschrieben werden die heute zum überwiegenden Teil keine Bedeutung mehr haben, es über mehrere Zwischenschritte (und Dokumente) aber dennoch zumindest auszugsweise bis in die heutige HD-Technik geschafft haben. Vielleicht ist das der Grund warum nur wenige Geräte heute ein digitales VPS unterstützen, obwohl z. B. ARD und ZDF in der Regel weiterhin zuverlässige und genaue Daten ausstrahlen.

Dieser Artikel beschreibt die vorhandenen Möglichkeiten und liefert ein Beispiel für eine sinnvolle Implementierung einer digitalen Aufnahmesteuerung.

Geschichte

VPS wurde in den 80er Jahren von ARD und ZDF entwickelt und wird seit 1985 ausgestrahlt. Das VPS-Signal wird in der 16. Videozeile übertragen. Nebenbei wurde zusätzlich Video Programming by Teletext (VPV oder VPT) entwickelt, das das Programmieren von Timern über den Teletext (Videotext) ermöglicht, indem man auf den Programmseiten (also üblicherweise die Seiten ab 300) die gewünschte Sendung auswählt und bestätigt. Dies erfordert speziell formatierte Teletext-Programmseiten die mit maschinenlesbaren Codes ergänzt sind.

In England wurde ab 1982 von der BBC das Broadcast Service Data Packet (BSDP), via Teletext Magazine 8 Packet 30 Type 0) gesendet, das auch Platz für eine Übertragung eines Programm-Identifikators (wie in Deutschland die VPS-Zeit) geboten hätte. Aus rechtlichen Gründen verzichtete man darauf (das Recht auf Fernsehaufnahmen für private Zwecke wurde erst 1989 in England eingeführt). Später wurde format 2 BSDP entwickelt, das nun u.a. diesen Programm-Identifikator beinhaltet.

Die Entwicklungen aus VPS, VPT und BSDP führten 1989 zu der gemeinsamen EBU-Spezifikation "Specification of the Domestic Video Programme Delivery Control System (PDC)". Diese sieht die Übertragung der PDC-Daten über die 16. Videozeile (VBI-Bereich) und/oder über Teletext (Magazine 8 Packet 30 Type 2) vor. Die Teletext-Übertragungsmethode bietet mehr Platz (z.B. gibt es dort das Prepare to Record Flag). In Deutschland wird aber i. d. R. nur die Übertragung über die dedizierte VBI-Zeile verwendet und das Programme Delivery Control wird weiterhin unter dem bekannten Begriff VPS vermarktet.

PIL

Zentraler Bestandteil von VPS/PDC ist das Programme Identification Label (PIL).

Die PIL enthält binär kodiert Tag, Monat, Stunde und Minute des angekündigten Beginns der Sendung (in Ortszeit). Das erste Bit nach folgender Tabelle ist das höchstwertigste.

1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20
Tag					Monat				Stunde					Minute

Beispiel: Berechnung der PIL in C++ mit den integer day, month, hour, minute:

pil = day << 15;
pil += month << 11;
pil += hour << 6;
pil += minute;

Service Codes

Beim analogen VPS/PDC gibt es die folgenden Service Codes, die zur Steuerung des Videorekorders dienen:

• "00000 1111 11111 111111": Timer-control Code (TC), der Videorekorder soll den Timer nach der programmierten Start- und Endzeit aufnehmen (z.B. wenn senderseitig ein Fehler aufgetreten ist)
• "00000 1111 11110 111111": Recording Inhibit/Terminate code (RI/T), Sendung vorbei
• "00000 1111 11101 111111": Interruption code (INT), Pause (die Sendung wird später fortgesetzt)
• "00000 1111 11100 111111": Continuation code, im Dokument heißt es: "indicating possibly an erroneous transmission state. No action required;"

Timing

Definitionsgemäß ist ein VPS-Code erst nach fünfmaligem fehlerfreien Empfang gültig. Für eine größtmögliche Genauigkeit bedeutet dies das sich der VPS-Code exakt 5 Frames vor einem neuen Event ändern muss.

Digitales VPS

Die VPS-Daten können und werden vielfach auch digital über die Teletext-PID auf Basis der Vertical Blanking Information (VBI) übertragen werden (data_unit_id 0xc3). Diese Daten sollen von Empfangsgeräten z. B. an den analogen Ausgängen oder von Kabelnetzbetreibern bei den analog eingespeisten Sendern eingefügt werden (in die 16. Videozeile). Auch ist weiterhin eine direkte Auswertung dieser Daten nach ETSI EN 300 231 für die Steuerung von digitalen Aufnahmen möglich. Dies wird aber bislang leider nur sehr wenig genutzt, obwohl damit theoretisch eine bildgenaue Steuerung möglich wäre.

Im DVB-Umfeld wurde das Thema Aufnahmesteuerung um einen weiteren Mechanismus ergänzt: Den Running-Status welcher als Teil des Electronic Programme Guide (EPG) übertragen wird.

Im Folgenden wird auf die Begriffe Running-Status und PDC-Descriptor aus dem DVB-SI EPG eingegangen.

Running-Status

In der Event Information Table (EIT) haben alle Events einen running_status. In der EIT schedule (table_id = 0x50-0x6f) ist dieser immer auf 0 (undefined) oder 5 (service off-air) gesetzt.

In der EIT present/following (table_id = 0x4e/0x4f) hat der running_status folgende Bedeutung:

running_status	present event (section_number = 0)	following event (section_number = 1)
0 [= undefined]	Das aktuelle DVB-Event als running behandeln.	Das folgende DVB-Event als not running behandeln.
1 [= not running]	Das angegebene Event hat noch nicht begonnen oder ist bereits vorbei.	Das folgende Event hat noch nicht begonnen.
2 [= starts in a few seconds]	Das angegebene Event wird in wenigen Sekunden beginnen.	Das angegebene Event wird in wenigen Sekunden beginnen.
3 [= pausing]	Das Event hat bereits begonnen, wurde unterbrochen (z.B. Werbung) und wird später fortgesetzt.	Das Event hat bereits begonnen, wurde durch ein anderes Event, das im present event angeben wird, unterbrochen und wird später fortgesetzt.
4 [= running]	Das angegebene Event läuft.	Diese Kombination ist nicht erlaubt.
5 [= service off-air]	Das aktuelle Event stellt den Sendeschluss (sendefreie Zeit) dar.	Das folgende Event stellt den Sendeschluss dar.
6-7 [= reserved for future use]

Die folgende Grafik zeigt den Zusammenhang zwischen den Zuständen:

Running Status Table (RST)

In der RST (PID 0x13, table_id 0x71) kann in Kombination mit ONID, TSID, SID der running_status eines DVB-Events angegeben werden wenn es zu einer Änderung kommt. Diese separate Tabelle (Section) ermöglicht eine schnellere und pünktlichere Übertragung als über die EIT (Zyklus 2 Sekunden), wodurch noch genauere Aufnahmen möglich sind.

In Deutschland nutzt derzeit kein Sender die RST.

Allerdings unterstützen einige SI-Systeme ein verkürztes EIT-P/F-Wiederholungsintervall bei einer Statusänderung. Dabei wird nach einer Statusänderung möglichst schnell das nächste EIT-P/F-Paket gesendet ohne die Zykluszeit abzuwarten um eine ähnlichen Effekt wie durch die RST zu erreichen.

PDC-Descriptor

Der PDC-Descriptor (descriptor_tag = 0x69) kann optional in der EIT zu jedem Event übertragen werden. Der Descriptor besteht nur aus der PIL, siehe oben. Service Codes dürfen nicht verwendet werden. Der PDC-Descriptor bzw. die PIL ist ein Identifikator für eine Sendung und darf im Nachhinein nicht mehr geändert werden. Eine Sendung kann sich über mehrere DVB-Events erstrecken.

Ein weiterer Vorteil durch den PDC-Descriptor ist, dass auch manuelle Timer unter Angabe der VPS-Zeit (PIL) programmiert werden können. Das ist besonders dann relevant, wenn der EPG des Senders nur wenige Tage in Voraus geht, d.h. die event_id noch nicht bekannt ist.

ARD und ZDF senden in ihrer EIT zusätzlich noch einen weiteren ähnlichen (nicht standardisierten) Descriptor mit descriptor_tag = 0x82 (Bereich user defined). Dieser dient der internen Steuerung der SI-Systeme bei der Auswertung der VBI-Informationen. Beispiel:

DVB-DescriptorTag: 105 (0x69)  [= PDC_descriptor]
descriptor_length: 3 (0x03)
reserved: 15 (0x0f)
Programme_identification_label: 0xd9d0f [= month=3  day=27   hour=20  min=15]

DVB-DescriptorTag: 130 (0x82)  [= User defined]
descriptor_length: 13 (0x0d)
Descriptor-data:
    0000:  32 30 3a 31 35 32 37 2e  30 33 23 30 30    20:1527.03#00

Dieser Descriptor enthält ASCII kodiert die VPS-Zeit im Format Stunde:MinuteTag.Monat, gefolgt von einem #. Die Zahl dahinter gibt an, um den wievielten DVB-Event mit gleicher VPS-Zeit es sich handelt.

Eine Auswertung dieses Descriptors scheint nicht sinnvoll zu sein, da nicht standardisiert und nur für interne Zwecke benötigt.

Implementierung

Das folgende Flussdiagramm zeigt eine sinnvolle Implementierung eines digitalen VPS auf Basis der EPG-Informationen:

Anmerkungen

• Mit der Überwachung des running_status sollte rechtzeitig vor dem geplantem Start der Sendung begonnen werden.
• Sollten alle Tuner gerade belegt sein, könnte überprüft werden, ob auf dem aktuellen TS eine EIT _other present/following (table_id 0x4f) angeboten wird, die den aufzunehmenden Sender enthält. In dem Fall braucht erst auf den Sender umgeschaltet werden, wenn der running_status des Events auf "running" oder "starts in a few seconds" wechselt. Allerdings werden die Informationen in der EIT _other in der Regel nur in deutlich längeren Abständen übertragen und können manchmal nicht zuverlässig sein.
• Digitale Aufnahmen lassen sich nicht unbedingt pausieren. Soweit es die Software zulässt, könnte z.B. zum Ende der Pause ein Marker gesetzt werden, zu dem der Benutzer bei der Wiedergabe springen kann. Es könnten auch Schnittmarker zum Beginn und Ende der Pause gesetzt werden.
• Die EIT present/following kann auch gerade fehlerhaft sein, obwohl der Sender üblicherweise zuverlässige Daten liefert. Eine einfache Erkennungsmethode könnte so aussehen, dass (aktuelle Zeit - Startzeit - Dauer des present event) gerechnet wird. Sollte diese Differenz zu groß sein, d.h. das als laufende angegebene Event hätte schon vor einiger Zeit/Stunden vorbei sein müssen, in dem Fall sollte der Receiver auf eine durch den Sender gesteuerte Aufnahme verzichten und nach der eigenen Uhr aufnehmen.
• Der Benutzer weiß nicht unbedingt, ob der aufzunehmende Sender zuverlässige Daten im running_status überträgt. Bei der Aktivierung von VPS für eine Aufnahme könnte daher überprüft werden, ob der Sender einen PDC-Descriptor in der EIT hat. Das Vorhandensein eines PDC-Descriptors kann ein Indiz dafür sein, dass der Sender zuverlässige Daten im running_status liefern könnte. Wenn der Descriptor nicht vorhanden ist, sollte der Benutzer informiert werden, dass der Sender möglicherweise kein VPS unterstützt.
• Sinnvoll könnte es sein, dem Benutzer zwei Modi anzubieten: Einem, in dem die Aufnahme komplett durch die Angaben im running_status gesteuert wird. Und einem Sicherheitsmodus, der dafür sorgt, dass der Timer zur programmierten Start- und Endzeit aufnimmt; das digitale VPS sorgt nur dafür, dass die Aufnahme ggf. früher startet oder länger dauert, aber nicht kürzer.
• Bei der Programmierung eines Timers sollten Start- und Endzeit normal eingegeben werden können. Wenn über den EPG programmiert wird, muss der Receiver die event_id im Timer speichern. Bei manuellen Programmierungen mit VPS muss eine VPS-Zeit (soweit vom Sender unterstützt, d.h. PDC-Descriptor vorhanden) angegeben werden. Um den o.g. Sicherheitsmodus realisieren zu können, muss diese VPS-Zeit getrennt von der Startzeit angegeben werden können.

Voraussetzungen auf Seiten des Senders

Wichtig ist, dass der DVB-Standard und bei Verwendung des PDC-Descriptors die PDC-Spezifikation vollständig eingehalten werden. Besonders wichtig in dem Zusammenhang sind zu erwähnen:

• Die SI-Daten müssen mit dem tatsächlichen Sendeablauf synchronisiert sein, d.h. der SI-Server muss direkt mit der Sendeabwicklung verbunden sein bzw. die PIL aus den dort generierten VPS Daten auswerten. Bei SD-SDI erfolgt die Übertragung per VBI-Datenzeile 16, bei HD-SDI Signalen über Ancillary Datenpakete (ANC) nach SMPTE 2031.
• Die event_id muss eindeutig sein und darf nicht geändert werden. Bei Ausfall einer Sendung darf die event_id nicht wieder verwendet werden. Die neue Sendung erhält eine eigene event_id.
• Bei Verwendung des PDC-Descriptors: Die PIL darf nur für eine Sendung verwendet und nicht mehr geändert werden. Sollte eine Sendung ausfallen, darf die PIL nicht wieder verwendet werden. Die neue Sendung erhält eine eigene PIL (z.B. eine Minute vor der PIL der ausgefallenen Sendung, statt 20:15 also 20:14).
• Das Timing des SI-Systems muss exakt an die internen Signallaufzeiten von Encodern oder Multiplexern angepasst werden. Dies ist aber insbesondere im SD/HD-Simulcastbetrieb oder bei mehreren unterschiedlichen Sendewegen schwierig, da die Encoder häufig stark unterschiedliche Verarbeitungszeiten aufweisen aber in der Regel nur ein gemeinsames SI-System eingesetzt wird.

Sender mit zuverlässiger Aufnahmesteuerung

Alle Sender von ARD und ZDF unterstützen digitales VPS und sie passen den Running-Status dem tatsächlichen Sendeablauf an. Zudem verwenden ARD/ZDF auch den PDC-Descriptor.

In Österreich unterstützt der ORF, in der Schweiz das SF und in Tschechien CT ebenfalls ein digitales VPS, inkl. PDC-Descriptor.

Das Timing der EIT-Änderungen und damit auch die Genauigkeit der EPG-basierten Aufnahmesteuerung kann abhängig vom Empfangsweg (SD, HD; Kabel, Satellit, DVB-T) variieren.

Unterstützte Receiver

• Dreambox, VU+ (und andere Receiver mit Enigma2) mittels VPS-Plugin (das Plugin wurde von einem Autor dieses Artikels entwickelt)
  • vollständige Unterstützung einschließlich PDC-Descriptor (außer RST)
  • Sicherheitsmodus möglich: Programmierte Start- und Endzeiten werden eingehalten. Die Aufnahme wird nur bei Bedarf früher gestartet oder dauert länger, aber nicht kürzer

• DVBViewer Pro mit Recording Service Erweiterung
  • vollständige Unterstützung einschließlich PDC-Descriptor (außer RST)
  • VBI-Daten (VPS/PDC) können für theoretisch fast framegenaues Timing (abhängig von der GOP-Struktur des MPEG2-TS) direkt ausgewertet werden
  • Automatische Behandlung von (Werbe)Unterbrechungen während einer Sendung.

Andere Receiver (es ist nicht bekannt, inwieweit die hier im Artikel genannten Möglichkeiten unterstützt werden):

• TechniSat (Isio-Modelle), vermarktet unter dem Begriff "Perfect Recording"
• Loewe unter "automatische Zeitsteuerung"
• VDR

Situation im Ausland

In England wird statt auf die DVB EIT schedule auf TV-Anytime gesetzt (Freeview/Freesat Plattform). Dort gibt es das sog. Accurate recording.

Es gibt hier einen dvb_binary_locator, der u.a. Informationen enthält, ob vom Sender eine genaue Steuerung der Aufnahme (via event_id oder TVA_id) möglich ist. Wenn nicht, gibt das Flag scheduled_time_reliability Auskunft darüber, ob die angegeben Sendezeiten im EPG einigermaßen zuverlässig sind. Wenn sie zuverlässig sind, kann der Sender eine Empfehlung für die einzuprogrammierende Vorlauf- und Nachlaufzeit eines Timers geben: early_start_window (0-7 Minuten) und late_end_window (0-62 Minuten).

Für die genaue Steuerung (falls angeboten) kennt TV-Anytime ebenfalls einen Running-Status mit den folgenden Zuständen:

• Not yet running
• Starts (or restarts) shortly
• Paused
• Running
• Cancelled
• Completed

Verbesserungsmöglichkeiten

Zur Steigerung der Benutzerfreundlichkeit ist es notwendig, dass der Sender eine Auskunft über die (derzeitige) Zuverlässigkeit seines running_status geben kann.

In Anlehnung an TV-Anytime könnte z.B. folgender fiktiver DVB-Descriptor für die SDT und EIT eingeführt werden:

Syntax	Bits
eit_reliability_descriptor() {
descriptor_tag	8
descriptor_length	8
descriptor_tag_extension	8
running_status_reliability	1
reserved_future_use	7
early_start_window	3
late_end_window	5
}

running_status_reliability: 1 steht für einen zuverlässigen Running-Status (d.h. der Running-Status wird dem tatsächlichen Sendeablauf angepasst). 0 steht für keine Zuverlässigkeit im Running-Status, aber einigermaßen zuverlässigen Zeitangaben in der EIT.

early_start_window: Angabe der Vorlaufzeit in 2er Schritten (0-14 Minuten). Falls running_status_reliability = 1, empfohlene Kontroll-Vorlaufzeit zur Überwachung des running_status. Falls running_status_reliability = 0, empfohlene einzuprogrammierende Vorlaufzeit für den Timer.

late_end_window: Angabe der Nachlaufzeit in 2er Schritten (0-62 Minuten). Falls running_status_reliability = 0, empfohlene einzuprogrammierende Nachlaufzeit für den Timer.

Der Descriptor sollte in der SDT vorhanden sein, um grundsätzlich über die Zuverlässigkeit des Senders zu informieren. Bei zusätzlicher Angabe im Event (in der EIT) wird die Information aus der SDT überschrieben. Dies erlaubt z.B. bei Live-Sendungen die Angabe eines längeren late_end_window. Wenn running_status_reliability in der SDT auf 1 und im present Event auf 0 gesetzt ist, wird dies als eine vorübergehende Störung angesehen. Die Sendung soll in dem Fall nach der programmierten Start- und Endzeit aufgenommen werden.

Die Abwesenheit des Descriptors wird so interpretiert, dass der Running-Status nicht zuverlässig ist (d.h. der Running-Status wird nicht dem tatsächlichen Sendeablauf angepasst) und es werden vom Sender auch keine Vor-/Nachlaufzeiten empfohlen.

Einzelnachweise

Hauptseite > Technik > Hintergrundinformationen > Digitales VPS