Cutlist.at-Feature-Request: Schnittmarken linear abfragen

[renne]

@Anatol:

Für Aufnahmen, die nicht von OTR stammen, ist eine lineare Abfrage der Schnittmarken sinnvoll.

D.h. der User gibt in der Suchmaske bzw. API den Namen des Senders, die Startzeit und die Laufzeit an. Daraufhin gibt die Suchmaske bzw. die API die Schnittmarken relativ zur Startzeit zurück. :-)

[anatol.at]

Das ist für Cutlist.at 2.0 auf alle Fälle ein interessantes Feature! Aktuell werden die Cutlists ja noch als Textdatei behandelt, das soll sich in 2.0 ändern - dann sollen die Cutlists geparst und strukturiert abgelegt werden.

Ein Offset-Tool wäre auch in der Schnittsoftware selbst wünschenswert, sodass man alle Schnitte gleichzeitig so verschieben kann, dass der Startframe zum aktuellen Frame verschoben wird. (Man sucht also den ersten Frame und alle anderen Schnitte werden automatisch mitverschoben.)

[renne]

Die Berechnung kann vielleicht auch die API machen. VDR z.B. verwendet Schnittmarken relativ zum Aufnahmestart im Format H:MM:SS.HH. Daher wäre es praktisch, wenn man z.B. einen VDR-Mode hätte, in dem die cutlist.at-API Sender, Startzeit und Aufnahmevorlauf bekommt und dann die Schnittmarken mit berechnetem Offset zurückgibt. :-) :-)

Für User, die MPEG-TS-Aufnahmen verwenden (DVB), ist es noch sinnvoll, die Werte des PTS-Counter zu nutzen (33-bit-Counter in MPEG-TS-Stream mit 90 kHz Frequenz). Der 33-bit Counter hat alle 26,5 Stunden einen Überlauf. In Verbindung mit dem Datum kann man damit exakt einen bestimmten Frame eines Senders indizieren. Da TV-Sender in der Regel für DVB-S/C/T den selben Hardware-Encoder verwenden, sind die PresentationTimeStamps einer Aufnahme für DVB-S/C/T identisch.

Deshalb halte ich es für sinnvoll, die Schnittmarken in einer Datenbank mit einem UNIX-Timestamp (alle Systeme haben Funktionen für die Umrechnung) + 1/100 Sekunden + PTS (sofern vorhanden) zu speichern.

P.S.: Statt einem Bewertungssystem für Schnittmarken halte ich auch eine statistische Optimierung der Schnittmarken für sinnvoll.
Wenn mehrere User Schnittlisten liefern, entstehen Schnittmarkenwolken, in denen jede Schnittmarke etwas von den Schnittmarken der anderen User abweicht. Berechnet man aber den Durchschnittswert der Schnittmarken, wird die Schnittmarke mit steigender Zahl von eingelieferten Schnittlisten immer präziser.

Im Grunde genommen kann die erste Schnittliste unpräzise sein, ein User der sie verwendet lädt dann seine korrigierte Version hoch, dann korrigiert der nächste User, etc. Bildet man den Durchschnittswert der eingelieferten Schnittmarken, konvergiert jede Schnittmarke immer gegen ihre optimale Position.

[anatol.at]

Klingt alles recht interessant, wird sich aber (aus ich glaube verständlichen Gründen) hinter vielen anderen Funktionen die eine höhere Priorität haben anstellen müssen...

[renne]

Wenn Du einen linearen Zeitstrahl (z.B. UNIX_Timestamp) als Schnittmarkenindex verwendest, können aber auch Nicht-OTR-User mitmachen. Die Umrechnung von OTR-Schnittmarken in UNIX-Timestamps ist sehr einfach:

In OTR-Dateinamen sind Jahr, Monat, Tag, Stunden und Minuten des EPG-Events kodiert. Mit der PHP-Funktion strtotime() (http://www.php.net/manual/de/function.strtotime.php) kannst' Du diese in einen Unix-Timestamp umrechnen (den auch MySQL und PostgreSQL kennen). Da OTR 600 Sekunden vor dem EPG-Event mit der Aufnahmen beginnt, brauchst' Du nur diese 600 Sekunden von Unix-Timestamp des EPG-Events abziehen, um den Unix-Timestamp der tatsächlichen Startzeit zu bekommen. Anschließend die Offsets der Schnittmarken addieren und Du hast fixe, in beliebigen Schnittsystemen verwendbare, UTC-Zeitstempel! ;-)