Patch zu vdrnfofs mit edl support

  • Hallo zusammen


    nachdem ich hier link eine vdrnfofs-version mit edl support gefunden habe, habe ich das auch sofort testen müssen.


    Dabei habe ich dann festgestellt, dass ohne eine marks-Datei defekte edl-Dateien erstellt werden.
    Die edl-Datei ist nicht nur leer, sondern kann gar nicht angefasst werden.
    NFS-Export geht dann auch nicht mehr.


    Meine Erweiterung erzeugt dann eine edl-Datei mit folgendem Inhalt
    00:00:00.000 99:99:99.99 2


    Jetzt muss ich nur noch XMBC zum Mitspielen überreden.


    Hier der geänderte Abschnitt aus filesystemnodes.py





    CU
    Helmut

    Fernsehzimmer: POV-Sydney ION mit Tevii S660 am Beamer, yaVDR 0.5
    Videoserver: GA-MA770T-UD3 mit 2xTBS 6981 Dual Tuner, Ubuntu 12.04 mit yaVDR 1.7.27 Paketen

  • Danke, das ist mir damals mangels entsprechender Aufnahmen mit fehlenden marks-Dateien nicht aufgefallen.

    Jetzt muss ich nur noch XMBC zum Mitspielen überreden.


    Was fehlt dir da noch? XBMC genügt es eigentlich wenn die edl genauso benannt ist wie die Videodatei

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Laut XBMC wicki müssen die actions NextScene/PreviousScene angesteuert werden. Bis jetzt haben meine Änderungen an den XML-Datenen noch nichts gebracht.


    Da fällt mir grade ein:
    gilt die edl-Funktionalität im Datei-Modus wie auch im Datenbank-Modus?:
    Dazu habe ich noch keinen Hinweis gesehen.



    CU
    Helmut

    Fernsehzimmer: POV-Sydney ION mit Tevii S660 am Beamer, yaVDR 0.5
    Videoserver: GA-MA770T-UD3 mit 2xTBS 6981 Dual Tuner, Ubuntu 12.04 mit yaVDR 1.7.27 Paketen

  • Laut XBMC wicki müssen die actions NextScene/PreviousScene angesteuert werden. Bis jetzt haben meine Änderungen an den XML-Datenen noch nichts gebracht.


    Hier klappt es - in der keyboard.xml sieht es so aus, das gleiche lässt sich auch auf die remote.xml usw. übertragen:


    Es spielt auch keine Rolle, ob man den Dateimodus nutzt oder es aus der Datenbank aufruft, hier bindet er die edl brav ein.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Moment mal, mit dem Skript stimmt etwas nicht. Die Zeitangaben passen nicht zusammen.
    In der EDL stehen, wenn ich das richtig sehe, Zeitstempel mit Sekundenbruchteilen.
    In der marks.vdr stehen aber entweder direkt Frame-Nummern (beginnend bei "1") oder Zeitstempel mit Frame-Nummer nach dem Punkt (beginnend bei "0:00:00.1").
    Ob sich XBMC aber ausgerechnet daran stört, bezweifle ich. Schlimmstenfalls sind die Sprungmarken halt etwas ungenau ...

    Give root password for maintenance (or type Control-D to continue): _

  • Ja, man bekommt dadurch bei Endmarken einen zu frühen Sprung (meist schlecht, da der Ton oft schon vor der Werbung auf Stereo wechselt und markad das wertet) und hüpft beim Anfang nach der Werbung etwas zu früh rein (was prinzipiell gut ist, da der Ton recht spät wieder auf Mehrkanal umgeschaltet wird) - bliebe ein zusätzliches Auslesen der Framerate aus der info-Datei und der Versuch das umzurechnen, um den i-Frame besser zu treffen - oder gleich zu runden, denn normalerweise mach es sich besser da vor einem Werbeblock ca. 1 Sekunde dazuzugeben und ca. 2s vor dem von Markad angegebenen Ende des Werbeblocks weiterzumachen...

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Wie wäre es so - oder gibt es was besseres um näher an den Zeitcode der i-Frames zu kommen?:

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Einmal editiert, zuletzt von seahawk1986 ()

  • Wie wäre es so - oder gibt es was besseres um näher an den Zeitcode der i-Frames zu kommen?:

    Braucht man den Zeitcode überhaupt? Im XBMC-Wiki steht nämlich, dass man Frames auch direkt angeben kann. Ich weiß aber nicht, ob die bei #0 oder #1 anfangen.


    Code
    tc = a.group(0)
                            hms = tc[:-2]
                            ff = tc[-2:]

    Ziemlich fragil, wenn du mich fragst. Ich würde eher den regulären Ausdruck um ein paar Gruppen erweitern. Also zum Beispiel:

    Code
    MARKS_FORMAT = re.compile(r'^((\d+):(\d+):(\d+)\.?)?(\d*[1-9]\d*)?')
    def mark_to_frame(mark, fps):
        m = MARKS_FORMAT.match(mark)
        if not m or not m.group():
            return None
        frame = int(m.group(5)) - 1 if m.group(5) else 0
        if m.group(1):
            hms = map(int, m.group(2, 3, 4))
            frame += (hms[0] * 3600 + hms[1] * 60 + hms[2]) * fps
        return frame

    Bei der Frame-Rate musst du aufpassen, weil die bei alten Aufnahmen nicht in der info.vdr steht, sondern fest auf 25,0 gesetzt ist, wenn ich mich nicht irre.

    Give root password for maintenance (or type Control-D to continue): _

    4 Mal editiert, zuletzt von tag () aus folgendem Grund: Funktion korrigiert

  • Braucht man den Zeitcode überhaupt?


    Die Frage ist halt ob man sich einen Gefallen damit tut die Frames auszurechnen statt hauptsächlich einen String zu kopieren - da wäre man von den Angaben in der info-Datei bis auf die Frames nach dem Timestamp unabhängig (dass die FPS nicht in der info-Datei stehen war AFAIK nur bei der summary.vdr der Fall, die unterstützt der Parser für die Info-Dateien von vdrnfofs aber sowieso nicht).


    Wiki und Manpage liefern interessanterweise unterschiedliche Angaben zum Format für die Schnittmarken (lustig, dass das seit 2007 niemandem aufgefallen ist): http://www.vdr-wiki.de/wiki/index.php/Dateiformat

    Zitat

    marks.vdr bzw. marks enthält die Schnittmarken. Es ist eine ASCII-kodierte Textdatei. In ungeraden Zeilen steht der Zeitpunkt einer Startmarke, in der darauf folgenden Zeile der der Endmarke. Das Format des Zeitpunktes ist h:mm:ss.HH mit h=Stunde, mm=Minute, ss=Sekunde und HH=Hundertstel. Beispiel: 1:03:43.22


    Während vdr(5) das sagt:

    Zitat

    The file marks.vdr (if present in a recording directory) contains the editing marks defined for this recording. Each line contains the definition of one mark in the following format:
    hh:mm:ss.ff comment
    where hh:mm:ss.ff is a frame position within the recording, given as "hours, minutes, seconds and (optional) frame number". comment can be any string and may be used to describe this mark. If present, comment must be separated from the frame position by at least one blank.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Die Frage ist halt ob man sich einen Gefallen damit tut die Frames auszurechnen statt hauptsächlich einen String zu kopieren - da wäre man von den Angaben in der info-Datei bis auf die Frames nach dem Timestamp unabhängig


    Dann teilt man eben die errechneten Frames nochmal durch fps und gibt Sekunden aus. Problem gelöst. ;)


    Ich habe sicherheitshalber nochmal direkt im VDR-Quelltext nachgeschaut (HMSFToIndex aus recording.c). Und zwar ist sowohl die Zeitangabe als auch der Frame optional. (Den Code aus meinem letzten Beitrag habe ich entsprechend geändert.) Also egal wofür man sich letztendlich entscheidet, irgendetwas muss man immer umrechnen.
    Umzurechnen hat aber auch Vorteile. Will man z.B. wissen, ob eine Marke am Anfang ist, muss man lediglich testen, ob der Frame == 0 ist, und braucht keine regulären Ausdrücke dafür. ;)


    (dass die FPS nicht in der info-Datei stehen war AFAIK nur bei der summary.vdr der Fall, die unterstützt der Parser für die Info-Dateien von vdrnfofs aber sowieso nicht).


    Ich meine die info.vdr von den "alten" Aufnahmen im PS-Format. Da steht definitiv keine Frame-Rate drin.

    Give root password for maintenance (or type Control-D to continue): _

  • Hi,


    coole sache mit dem EDL. Ich habe basierenden auf den aktuellen Erkenntnissen mal ein (D)Patch gebastelt, damit man sich nicht alles zusammensuchen muss. Dieser (D)Patch ist gegen das YaVDR-Repo erstellt worden und eben auch damit kompatibel.


    MfG
    KRis

Jetzt mitmachen!

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