RFC: Frames von 0 zählen

  • Aus irgend einem Grund, den ich heute leider nicht mehr weiß, werden in VDR die Frames mit 1 beginnend gezählt und nicht, wie sonst üblich, von 0. War vielleicht einfach eine falsche Entscheidung in den Anfangstagen von VDR...


    Prinzipiell ist es zwar egal, ob von 0 oder 1 gezählt wird, aber es ärgert mich jedesmal wieder, wenn ich irgendwo einen Timecode mit Frames sehe, und dort laufen die Frame-Nummern eben von 0 bis 24, wie es sich anscheinenend gehört.


    Ich würde das daher gerne endlich mal fixen, was vom Eingriff her relativ einfach ist:


    Die Anzeige der Frame-Nummer beim Bewegen einer Schnittmarke wäre damit sofort richtig.
    Einziger Nachteil: bestehende Schnittmarken wären alle um 1 daneben. Das wäre aber nicht weiter schlimm, denn seit Version 1.7.32 werden beim Einlesen alle Schnittmarken wenn nötig zum nächstgelegenen I-Frame hin verschoben. Somit könnte ein aktueller VDR nach wie vor alle früheren Aufnahmen problemlos handhaben, und alle VDR-Versionen seit 1.7.32 könnten genauso neue Aufnahmen verarbeiten. Was nicht gehen würde wäre, eine neue Aufnahme, die mit obigem Patch gemacht wurde und Schnittmarken enthält, mit einer VDR-Version vor 1.7.32 zu schneiden. Diesen Fall würde ich aber als eher unwahrscheinlich und daher vernachlässigbar einstufen. Die reine Wiedergabe mit älteren Versionen wäre kein Problem, da sich am eigentlichen Aufzeichnungsformat ja nichts ändert.


    Ich würde diese Änderung gerne machen, möchte aber vorher mal in die Runde fragen, ob es Einwände gibt. Vielleicht übersehe ich ja noch irgendein Problem...


    Klaus

  • Moin!


    Prinzipiell hab ich nie was dagegen, wenn alte Fehler korrigiert werden. Da die 1.7er sowieso Developer-Releases sind und alle Distributionen Zeit genug hatten, auf 2.0.x zu wechseln, wären höchstens die betroffen, die noch einen 1.6 betreiben. Der kann mit neuen Aufzeichnungen im TS-Format aber sowieso nichts anfangen.


    Alternative und evtl. für die Zukunft brauchbar:
    Wie wäre es mit einer Versionsnummer in der info-Datei? Nicht vorhanden könnte man mit 0 gleichsetzen, Aufnahmen mit diesem Patch legen Version 1 ab. Sollte es mal wieder inkompatible Änderungen geben, zählt man diese Version einfach hoch. Und der aktuelle vdr könnte bei einer höheren als erwarteten Versionsnummer zumindest eine Logmeldung ausgeben bzw. außer Abspielen sämtliche Be-/Verarbeitungspunkte verweigern. Zumindest das Prüfen ließe sich auch noch in den 2.0.x aufnehmen.


    Ich sehe gerade, in der marks-Datei kann man auch Kommentare hinter dem Zeitstempel ablegen. Ob man evtl. das dafür nutzt? Wofür sind die eigentlich bisher gedacht?


    Lars.

  • Da die 1.7er sowieso Developer-Releases sind und alle Distributionen Zeit genug hatten, auf 2.0.x zu wechseln, wären höchstens die betroffen, die noch einen 1.6 betreiben.


    Mal sehen was die Jungs von BM2LTS dazu sagen.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470


  • Prinzipiell hab ich nie was dagegen, wenn alte Fehler korrigiert werden. Da die 1.7er sowieso Developer-Releases sind und alle Distributionen Zeit genug hatten, auf 2.0.x zu wechseln, wären höchstens die betroffen, die noch einen 1.6 betreiben. Der kann mit neuen Aufzeichnungen im TS-Format aber sowieso nichts anfangen.


    Sehe ich genauso. Wer also mit "stable" Versionen arbeitet sollte in keiner der beiden Richtungen irgend ein Problem haben.


    Zitat


    Alternative und evtl. für die Zukunft brauchbar:
    Wie wäre es mit einer Versionsnummer in der info-Datei? Nicht vorhanden könnte man mit 0 gleichsetzen, Aufnahmen mit diesem Patch legen Version 1 ab. Sollte es mal wieder inkompatible Änderungen geben, zählt man diese Version einfach hoch. Und der aktuelle vdr könnte bei einer höheren als erwarteten Versionsnummer zumindest eine Logmeldung ausgeben bzw. außer Abspielen sämtliche Be-/Verarbeitungspunkte verweigern. Zumindest das Prüfen ließe sich auch noch in den 2.0.x aufnehmen.


    Oder ähnlich wie bei den Plugins: die VDR-Versionsnummer, mit der die Aufnahme erzeugt wurde, und die Mindest-Versionnummer die benötigt wird, um die Aufnahme abzuspielen. Wobei das für die aktuelle Developerversion dann 2.1.4/1.7.3 wäre.
    Durch die Änderung der Frame-Nummerierung würde das dann in der nächsten Version zu 2.1.5/1.7.32, wenn man es ganz streng sieht. Aber die Aufnahme wäre ja auch bis zurück zur 1.7.3 zumindest noch abspielbar. Sollte man da dann noch feiner unterscheiden? Aber wie sollte das gehen? Etwa mit drei Versionsnummern? "Erzeugt mit.../abspielbar ab.../editierbar ab..."? Bräuchten wir noch weitere?


    Zitat


    Ich sehe gerade, in der marks-Datei kann man auch Kommentare hinter dem Zeitstempel ablegen. Ob man evtl. das dafür nutzt? Wofür sind die eigentlich bisher gedacht?


    Da hatte ich mal gedacht, man könnte vielleicht für den Benutzer lesbare Markierungstexte ("Kapitelnamen" oder sowas) angeben. Das wurde im VDR aber nie verwendet und ich trage mich mit dem Gedanken, das irgendwann mal ganz fallenzulassen.


    Klaus


  • Mal sehen was die Jungs von BM2LTS dazu sagen.


    Dann haben die mal einen Grund, auf 2.0.x zu wechseln. :)
    Wieso haben die das nicht schon längst?


    Lars.

  • Da hatte ich mal gedacht, man könnte vielleicht für den Benutzer lesbare Markierungstexte ("Kapitelnamen" oder sowas) angeben. Das wurde im VDR aber nie verwendet und ich trage mich mit dem Gedanken, das irgendwann mal ganz fallenzulassen.


    OT: Bitte nicht! Als Musikliebhaber und VDR-Konzertaufnahmen-Vielgucker wollte ich zu gegebener Zeit eigentlich mal einen Vorstoss starten, ein solches Feature zu implementieren! Denn Kapitelmarken sind das einzige Feature, dass mir beim VDR noch fehlt und somit eigentlich die alleinige Existenzberechtigung meines BD-Players im Wohnzimmer.


    Gruss
    Thomas

  • Oder ähnlich wie bei den Plugins: die VDR-Versionsnummer, mit der die Aufnahme erzeugt wurde, und die Mindest-Versionnummer die benötigt wird, um die Aufnahme abzuspielen. Wobei das für die aktuelle Developerversion dann 2.1.4/1.7.3 wäre.
    Durch die Änderung der Frame-Nummerierung würde das dann in der nächsten Version zu 2.1.5/1.7.32, wenn man es ganz streng sieht. Aber die Aufnahme wäre ja auch bis zurück zur 1.7.3 zumindest noch abspielbar. Sollte man da dann noch feiner unterscheiden? Aber wie sollte das gehen? Etwa mit drei Versionsnummern? "Erzeugt mit.../abspielbar ab.../editierbar ab..."? Bräuchten wir noch weitere?


    Momentan fällt mir kein weiterer Anwendungsfall ein. Ich würde alles, was über Abspielen hinausgeht (schneiden, kopieren usw.) einfach in der dritten Versionsnummer zusammenfassen. Beim nächsten stable-Release wird die sich ja innerhalb des stable-Release nicht mehr verändern. Oder man müsste die Aktion mit zur Versionsnummer schreiben, wie z.B. rec=2.1.5/play=1.7.32/cut=.../copy=.../other=2.1.5 usw. Aber das halte ich für zu weit gedacht.


    Da hatte ich mal gedacht, man könnte vielleicht für den Benutzer lesbare Markierungstexte ("Kapitelnamen" oder sowas) angeben. Das wurde im VDR aber nie verwendet und ich trage mich mit dem Gedanken, das irgendwann mal ganz fallenzulassen.


    Ok. Kapitelnamen wären zwar ganz lustig, aber wenn man in einer fertigen Aufnahme, die man nicht weiter schneiden will, eine einzelne Markierung setzt, würde es ja sowieso ein komisches Resultat ergeben, falls man die doch zufällig schneidet.
    Falls man mal wirklich solche Namen haben möchte, könnte man immer noch eine neue Datei "chapters" einführen. Dann wissen auch Plugins bescheid, die eine Aufnahme z.B. in eine DVD oder mkv umwandeln, wie sie das Ergebnis noch schöner machen können.


    Lars.

  • oder den Kommentar bis zur nächsten Marke in das Bild einblenden.
    dann könnte man ganz einfach eigene Untertitel erstellen
    und diese durch Verschieben der Marken auch noch
    genau positionieren


    Das könnte mir gefallen.


    zum Thema :
    Marken setzen und Schneiden passiert normalerweise auf dem selben VDR.
    Ich habe auch noch ältere VDRs am laufen und es würde nicht stören.

    vdr 1.7.23 suse 12.1 64 Bit 1xTTS2-6400 HD-USB: 24TB
    vdr 1.7.23 suse 11.3 64 Bit 1xTTS2-6400, 1xTTS2-3200 + ci HD:2TB
    vdr 2.2.0 Raspberry pi HD-USB: 2TB (Garten)

  • Da hatte ich mal gedacht, man könnte vielleicht für den Benutzer lesbare Markierungstexte ("Kapitelnamen" oder sowas) angeben. Das wurde im VDR aber nie verwendet und ich trage mich mit dem Gedanken, das irgendwann mal ganz fallenzulassen.


    Das cutalot-Plugin hatte die Namen mal benutzt. Aus dessen README:

    Irgendwann hat's dann aber mit TS nicht mehr compiliert ....


  • Dann haben die mal einen Grund, auf 2.0.x zu wechseln. :)
    Wieso haben die das nicht schon längst?


    AFAIK können die das nicht. Ich glaube das hat was mit ihrer Unterstützung der eHD zu tun.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • AFAIK können die das nicht. Ich glaube das hat was mit ihrer Unterstützung der eHD zu tun.


    Macht ja nichts, es wäre ja nur ein Problem, wenn die eine Aufnahme in ihr System von einem neueren vdr kopieren und ihn dann schneiden möchten.


    Lars.

  • Genau so ist es.


    Eben aus dem Grund frage ich mich auch schon die ganze Zeit ob der Aufwand, jetzt irgendwelche Versionsnummern zu führen, überhaupt gerechtfertigt ist. Nur ein ganz kleiner Bereich von Entwickler-Versionen ist problematisch und den Benutzern dieser Versionen kann jetzt mit der Versions-Nummer sowieso nicht mehr geholfen werden.


    Man muss beim Übernehmen einer Aufnahme von einem neuen VDR eigentlich nur daran denken die "marks"-Datei zu löschen. Fertig. Wobei ich mich frage ob die betroffenen überhaupt TS-Aufnahmen nutzen können. War es nicht so, dass für die eHD deshalb eine alte VDR-Version genutzt wird, weil die Plugins für die eHD nie für TS fit gemacht wurden?


  • Eben aus dem Grund frage ich mich auch schon die ganze Zeit ob der Aufwand, jetzt irgendwelche Versionsnummern zu führen, überhaupt gerechtfertigt ist. Nur ein ganz kleiner Bereich von Entwickler-Versionen ist problematisch und den Benutzern dieser Versionen kann jetzt mit der Versions-Nummer sowieso nicht mehr geholfen werden.


    Es ist sowieso problematisch, in der 'info'-Datei neue Tags einzuführen. Wenn cRecordingInfo::Read() auf ein solches Tag stößt, dann bricht es das weitere Einlesen mit einer Fehlermeldung im Log ab. Alles bis dahin eingelesene ist zwar richtig gespeichert, der Rest geht aber verloren. Wenn man neue Tags immer am Ende der Datei anfügt, dann ist das nicht allzu schlimm, denn ältere Versionen lesen dann halt alles bis zum ersten unbekannten Tag und ignorieren den Rest. Ich werde das wohl so ändern, daß im Falle eines unbekannten Tags einfach nur dieses übersprungen und dahinter weitergelesen wird.


    Die Änderung der Frame-Nummerierung hatte ich zwischenzeitlich auch für die kommende Stable-Version 2.0.6 gemacht, werde dies aber wohl wieder rückgangig machen, da es innerhalb der 2.0.x keine inkompatiblen Änderungen geben soll. Oder ist jemand der Meinung, das sollte auch bereits in die 2.0.6 einfließen?


    Klaus

  • Ich finde auch, dass 2.0.x nur Bugfixes bekommen sollte. Das hier ist ja fast eher ein neues "Feature". :)
    Und ich halte es für eine gute Idee, unbekannte Tags einfach zu überspringen, solange sie beim Schreiben auch wieder in der Datei landen. Das wäre auch was für 2.0.6.


    Das macht das Experimentieren mit Erweiterungen für die info-Datei leichter. Falls man dann mal eine Aufnahme weitergibt, hat der Empfänger dann kein Problem.


    Lars.

  • Die Frage ist: Ist die Änderung inkompatibel? Vor allem im Hinblick auf Plugins. Könnte das dort Probleme machen? Wenn ja, dann wohl lieber aus der 2.0 erstmal noch rauslassen.


    Es ist wohl so eine Grauzone. Die Version 2.0.x kann Frame-Nummern, die um eins daneben liegen, problemlos einlesen. Aber was ist mit Tools, die Werbepausen erkennen und passende 'marks'-Dateien schreiben? Lesen die auch 'marks', die von VDR erzeugt wurden, ein? Könnten die dadurch durcheinanderkommen?


    Klaus

  • Aber was ist mit Tools, die Werbepausen erkennen und passende 'marks'-Dateien schreiben? Lesen die auch 'marks', die von VDR erzeugt wurden, ein? Könnten die dadurch durcheinanderkommen?

    Guter Einwand: IMHO schreiben die die marks-Datei nur, aber die wären ja dann auch alle eins daneben. VDR kann die zwar einlesen, aber kann es da Rundungsfehler geben, so dass z.B. die Marke auf dem falschen GOP sitzt?
    Ob ich bei burn was anpassen müsste überblicke ich grade nicht, weil da viele VDR-Funktionen benutzt werden um die BytePos zum Schneiden zu bestimmen.
    Mein marks2bytepos-Skript wäre auch betroffen. Wenn ich das richtig sehe müsste zwar nur einmal das "-1" weg, aber es wäre schön, wenn man das an der marks-Datei erkennen könnte. Wenn die z.B. marksv2 anstatt marks heißt? oder marksts :versteck
    Dann könnte VDR sogar ne marks einlesen und als marksts schreiben falls sie noch nicht existiert...

  • Versionsinfo wäre ohnehin gut für alle automatisch erzeugten bzw. automatisch veränderten Textdateien. Das erleichtert die Zusammenarbeit mit externen Tools.

  • Die Anzeige der Frame-Nummer beim Bewegen einer Schnittmarke wäre damit sofort richtig.
    Ich würde diese Änderung gerne machen, möchte aber vorher mal in die Runde fragen, ob es Einwände gibt. Vielleicht übersehe ich ja noch irgendein Problem...


    Könnte man in dem Zusammenhang den Inhalt Datei "resume" auch lesbarer machen, also die Angaben so wie in der "marks" Datei?

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!