Verteilte Datenbank für den Schnittlistenaustausch

[renne]

Hallo,

bisher ist der Austausch der Schnittlisten mehr oder weniger unorganisiert. Jeder Videorekorderdienst und jede Videorekorderanwendung verwendet ein eigenes, inkompatibles System. Die Folge ist, dass Schnittlisten nur langsam, ungenau und nicht für alle Aufnahmen verfügbar sind.

Bei DVB kann jedes Programm eindeutig durch die Kombination der 16-bit ONID (Original Network ID) und der 16-bit SID (Service ID) identifiziert werden. Deshalb ist es recht einfach, eine globale, verteilte Datenbank zu nutzen. Viele TV-Sender nutzen für mehrere Übertragungswege denselben Video-Encoder. Dadurch können Schnittlisten über eine Mapping-Tabelle sogar auf verschiedene Satelliten, Kabelanschlüsse und terrestrische Sender angewendet werden.

Benötigte Datensätze:

Schnittmarkentabelle
1. ONID (16 bit)
2. SID (16 bit)
3. UNIX-Zeitstempel der Schnittmarke im Video (64-bit)
4. hundertstel Sekunde des UNIX-Zeitstempels der Schnittmarke im Video (7 bit)
5. öffnende oder schließende Schnittmarke (1 bit)
6. UNIX-Zeitstempel der Erzeugung des Datensatzes (64-bit)

Mapping-Tabelle
1. ONID (16 bit)
2. SID (16 bit)
3. alternative ONID (16 bit)
4. alternative SID (16 bit)
5. UNIX-Zeitstempel der Erzeugung des Datensatzes (64-bit)

Wird ein P2P-System verwendet, gibt es kein zentrales Element, welches Ausfallen oder seinen Dienst einstellen kann. Durch eine statistische Funktion kann das Schnittprogramm die Mittelwerte der Schnittmarken aller Nutzer errechnen.

Ein erster Schritt seitens OTR wäre das Einfügen der ONID, SID und eines millisekundengenauen 64-bit UNIX-Timestamps des Aufnahmebeginns in die Metadaten aller Aufnahmen.

[hugo2514]

Timestamps des Aufnahmebeginns
Der müßte ja dann mit einem sehr genauen Zeitserver abgeglichen werden.
Und die Art des DVB-Datenstroms wäre auch noch nötig, schließlich haben die verschiedenen Verfahren unterschiedliche Verzögerungen und somit auch unterschiedliche Startzeiten.
Und kaum ist mal ein Server nicht exakt synchronisiert, kann man dessen Angaben nicht mehr gebrauchen.
Da muß wirklich Einiges passen und stimmen, damit es funktioniert...

[renne]

Der müßte ja dann mit einem sehr genauen Zeitserver abgeglichen werden.

Bei einer Framerate des Videos von 50 Hz reicht eine Auflösung in hundertstel Sekunden (Frequenz * 2) um einen Frame eindeutig zu identifizieren. Ein NTP-Client mit Drift-Korrektur (z.B. NTPd mit ptbtime1.ptb.de und ptbtime2.ptb.de als Referenz) sollte das schaffen (https://de.wikipedia.org/wiki/Network_Time_Protocol#Algorithmus_und_Genauigkeit) . Zusätzlich kann man noch den Presentation Timestamp (PTS) und die Program Clock Reference (PCR) im DVB-Datenstrom verwenden, um die Drift über einen Kalman-Filter zu korrigieren (http://linuxtv.org/wiki/index.php/Kalman_Filtering_for_STC/PCR_smoothing).


Und die Art des DVB-Datenstroms wäre auch noch nötig, schließlich haben die verschiedenen Verfahren unterschiedliche Verzögerungen und somit auch unterschiedliche Startzeiten.
DVB-Pakete werden in Bursts übertragen. Wann ein Frame durch den Dekoder angezeigt wird, entscheidet der Presentation Timestamp im DVB-Datenstrom. Sofern alle Übertragungswege denselben Encoder mit identischen Presentation Timestamps verwenden, können die Schnittmarken eines Übertragungsweges direkt auf alle anderen übertragen werden. Sind die Presentation Timestamps nicht identisch, muss der entsprechende Offset (z.B. über eine Tabelle mit einem Offset-Eintrag pro Tag) mit einbezogen werden. Aus der ONID lässt sich übrigens der Übertragungsweg/die Quelle entschlüsseln (http://www.dvbservices.com/identifiers/original_network_id).


Und kaum ist mal ein Server nicht exakt synchronisiert, kann man dessen Angaben nicht mehr gebrauchen. Wenn der NTP-Client direkt in die Aufnahmesoftware intergriert wird, sehe ich da kein Problem.

[Artemis1121]

schöne Idee, aber OTR hat nicht mal die Ressourcen um den easydekoder weiterzuentwickeln oder jemanden, dersich um den arm Dekoder kümmert (http://otrforum.com/showthread.php?69486-Linux-ARM-Decoder-Kommandozeilenversion-f%FCr-RaspBMC-u-a/page5).. Wenn Aufnahmesoftware existiert die sich um alles kümmert, kann man denke ich otr drauf ansprechen.. aber so wirds wohl nix!
Für OTR funktioniert das aktuelle System mit cutlist.at ja sehr gut.. da gibts wenig Leidensdruck was zu ändern!

[renne]

Wenn Aufnahmesoftware existiert die sich um alles kümmert, kann man denke ich otr drauf ansprechen.. aber so wirds wohl nix! Für OTR funktioniert das aktuelle System mit cutlist.at ja sehr gut.. da gibts wenig Leidensdruck was zu ändern!

Solange OTR eine ernsthafte Konkurrenz fehlt, wird's wohl bei hoher Quantität und mieser Qualität bleiben. Deshalb wäre es schön, über ein solches System qualitativ hochwertige Schnittlisten zu bekommen. Solange die TV-Kanäle der OTR-Aufnahmen aber nicht eindeutig identifizierbar sind, wird sich niemand an eine entsprechende Schnitt-Software wagen. Aus dem EPG-Parser ONID und SID auszulesen und in die Meta-Daten der Aufnahmen zu schreiben, sollte kein Problem sein. Die Zeit lässt sich auch einigermaßen synchronisieren, indem OTR den UNIX-Timestamp des Starts in die Meta-Daten der Aufnahme schreibt und die Aufnahme millisekundengenau auf die volle Sekunde startet.

[hugo2514]

Solange OTR eine ernsthafte Konkurrenz fehlt, wird's wohl bei hoher Quantität und mieser Qualität bleiben.
Huch, redest Du wirklich von OTR?
Klar, es ist nicht perfekt, aber alles andere als mies.

[Artemis1121]

Solange OTR eine ernsthafte Konkurrenz fehlt, wird's wohl bei hoher Quantität und mieser Qualität bleiben. Deshalb wäre es schön, über ein solches System qualitativ hochwertige Schnittlisten zu bekommen. Solange die TV-Kanäle der OTR-Aufnahmen aber nicht eindeutig identifizierbar sind, wird sich niemand an eine entsprechende Schnitt-Software wagen. Aus dem EPG-Parser ONID und SID auszulesen und in die Meta-Daten der Aufnahmen zu schreiben, sollte kein Problem sein. Die Zeit lässt sich auch einigermaßen synchronisieren, indem OTR den UNIX-Timestamp des Starts in die Meta-Daten der Aufnahme schreibt und die Aufnahme millisekundengenau auf die volle Sekunde startet.


Die Schnittlisten sind eindeutig den OTR Dateien und die Schnittstellen exakt auf die einzelnen Bilder zugeordnet. Am Dateinamen kann man auch Sender, Start- und Endzeit erkennen.
Für OTR-Aufnahmen sehe ich keine Vorteile durch die von dir vorgeschlagene Änderung.
Vorteilhaft wäre dies nur für eigene Sataufnahmen, die man dann mit den OTR-Schnittlisten schneiden könnte, oder für andere Videodienste.
Was für einen Vorteil siehst du für OTR? Würde sich der Aufwand lohnen? Ich sehe das irgendwie nicht..