SeamlessCut: Mit den Schittmarken passieren seltsame Dinge...

  • Die Beobachtungen beziehen sich aktuell auf VDR 2.0.6. Da fraglichen Stellen seither aber nicht geändert wurden, sollte der das Problem noch immer bestehen.
    (Die Probleme treten nur selten und in Abhängigkeit der Schnittmarken auf. Daher ist es mir leider erst aufgefallen, als ich den neuen VDR schon eine Weile produktiv in Betrieb hatte. Und aufgrund der Struktur meiner Aufnahmeverzeichnisse, kann ich momentan nicht so ohne weiteres mal kurz auf einen VDR > 2.0.x wechseln.)



    Zuerst einmal sind die Schnittmarken auf einer Position jetzt beliebig oft "stapelbar".
    Das sieht in der "marks"-Datei dann so aus:

    Code
    1. 0:00:02.11
    2. 0:00:08.15
    3. 0:00:16.19
    4. 0:00:16.19
    5. 0:00:16.19
    6. 0:00:16.19
    7. 0:00:16.19
    8. 0:00:27.08


    Probleme verursacht das aber nicht, sofern man von dem unerwarteten Verhalten beim Verschieben einer der (gestapelten) Schnittmarken absieht.




    Das nächste Problem ist da deutlich gravierender:
    Manche Schnittmarken, unter anderem die bei SeamlessCuts, verschwinden beim Schnitt einfach! D.h. nach mehreren Schnitten sind dann irgendwann keine Marken mehr da.
    Hauptursache ist ein Fehler in der "recording.c", der dazu führt, dass die SeamlessCuts komplett ignoriert werden. Der Cutter bekommt vom SeamlessCuts also überhaupt nichts mit.
    Die entsprechenden Routinen werden garnicht angesprochen, die eingefügten Debug-Ausgaben (siehe Patch im Anhang) erscheinen nie im Log.


    Der angehängt Patch stellt das, meiner Ansicht nach, ursprünglich beabsichtigte Verhalten her und beseitigt bei mir die Probleme.
    Alle (sinnvollen) gesetzten gesetzten Schnittmarken bleiben jetzt erhalten, mit Ausnahme der am Ende. (Da die Position der Endmarke weggeschnitten wird ist das leider nicht möglich.)
    "Stapelmarken" werden auf die sinnvolle Anzahl, also 1 bei einer ungeraden und 2 bei einer geraden Anzahl an "gestapelter" Marken reduziert. "SeamlessINCuts", also Sequences mit der Länge 0, werden entfernt.
    Das Wichtigste ist aber, dass sich jetzt bei einem erneuten Schnitt der geschnittenen Aufnahme, nichts mehr verändert. Die .ts, index und marks Dateien bleiben Identisch.


    Ich habe den Patch intensiv getestet und auch alle Sonderfälle berücksichtigt, die mir eingefallen sind: Also "Stapelmarken" an Anfang oder Ende "SeamlessINCuts" usw. und konnte kein Fehlverhalten feststellen.
    Lediglich bei Aufnahmen, die nur "SeamlessINCuts" beinhalten entstehen 0 Byte Videos. Das ist nicht wirklich sinnvoll, verursacht aber keine Probleme, auch nicht, wenn man versucht das Ergebnis abzuspielen. Den Sonderfall extra abzufangen braucht man also, denke ich, nicht.

    Files

    Gruss
    SHF


  • Auch auf die Gefahr das es was alltägliches ist, was ist SeamlessCut?


    Regards
    fnu

    HowTo: APT pinning

  • Auch auf die Gefahr das es was alltägliches ist, was ist SeamlessCut?


    Die selbe Frage hab ich mir auch gestellt. Übersetzt: nahtloses Schneiden, darunter vorstellen kann ich mir aber nichts.

    - Client1: Thermaltake DH 102 mit 7" TouchTFT * Debian Stretch/vdr-2.4.0/graphtft/MainMenuHooks-Patch * Zotac H55-ITX WiFi * Core i3 540 * 4GB RAM ** Zotac GT630 * 1 TB System HDD * 4 GB RAM * Harmony 900 * satip-Plugin

    - Client2: Alfawise H96 Pro Plus * KODI
    - Server: Intel Pentium G3220 * DH87RL * 16GB RAM * 4x4TB 3.5" WD RED + 1x500GB 2.5" * satip-Plugin
    - SAT>IP: Inverto iLNB

  • Schon klar was das heißt :rolleyes:, habe den Begriff aber noch nie im Zusammenhang mit VDR gehört. Ist das was der VDR sowieso schon macht, ein Patch ... ?


    Regards
    fnu

    HowTo: APT pinning

  • Muss man die marks von Hand bearbeiten, um das Verhalten zu erreichen?


    Code
    1. 0:00:02.11
    2. 0:00:08.15
    3. 0:00:16.19
    4. 0:00:16.19
    5. 0:00:16.19
    6. 0:00:16.19
    7. 0:00:16.19
    8. 0:00:27.08


    Macht ja eigentlich keinen Sinn und ich glaube auch nicht, dass der VDR das macht, wenn man Schnittmarken setzt.

    - Client1: Thermaltake DH 102 mit 7" TouchTFT * Debian Stretch/vdr-2.4.0/graphtft/MainMenuHooks-Patch * Zotac H55-ITX WiFi * Core i3 540 * 4GB RAM ** Zotac GT630 * 1 TB System HDD * 4 GB RAM * Harmony 900 * satip-Plugin

    - Client2: Alfawise H96 Pro Plus * KODI
    - Server: Intel Pentium G3220 * DH87RL * 16GB RAM * 4x4TB 3.5" WD RED + 1x500GB 2.5" * satip-Plugin
    - SAT>IP: Inverto iLNB


  • Was ist das denn für ein "unerwartetes Verhalten"?



    Ich habe das mal ausprobiert, aber es sind zwei Probleme aufgetaucht:


    - Mit diesem Patch funktioniert das in 2.1.8 eingeführte "Skip edited parts" (aka "playjump") nicht mehr.
    - Wenn aus einer Aufnahme nur ein einzelnes Stück rausgeschnitten wird, enthält die geschnittene Fassung eine Schnittmarke am Anfang (das wurde in Version 1.7.32 absichtlich geändert, so daß in einem solchen Fall *keine* Schnittmarken vorhanden sind).


    Daß aufeinanderliegende Schnittmarken "verschwinden", wenn eine geschnittene Aufnahme nochmal geschnitten wird, ist wohl verschmerzbar. Typischerweise wird eine Aufnahme ja nur *einmal* geschnitten und das wars dann.


    Nachdem das Verhalten der Schnittmarken jetzt seit mehr als zwei Jahren so ist, wie es jetzt ist, kann ich da für die 2.2.0 wohl nichts mehr ändern. Insbesondere, wo der Patch bestehende Funktionen beschädigt.


    Klaus


  • - Mit diesem Patch funktioniert das in 2.1.8 eingeführte "Skip edited parts" (aka "playjump") nicht mehr.


    Korrektur: das könnte ein vorschneller Schluß gewesen sein, da ich heute auch ohne diesen Patch beobachtet habe, daß das Überspringen der Werbepause einmal nicht funktioniert hat, als ich mit '8' einen Testlauf gemacht hatte.
    Muß ich nochmal genauer ausprobieren...


    Klaus

  • Auch auf die Gefahr das es was alltägliches ist, was ist SeamlessCut?


    Der SeamlessCut muss im Zusammenhang mit dem neuen Cutter, der die Übergänge korrigiert, eingeführt worden sein oder kurz davor.
    Das ist, wenn zwei Sequenzen direkt aufeinander stossen. Das heisst die Schnittmarken sind auf der selben Position.
    Der SeamlessCut ist also ein Schnitt, der eigentlich keiner ist und auch nicht korrigiert werden muss.


    Ich dachte, der Begriff ist bekannter, ich hoffe das ist verständlich (und korrekt) erklärt.



    Muss man die marks von Hand bearbeiten, um das Verhalten zu erreichen?

    Nein, natürlich nicht!


    Man kann die Marken ganz bequem mit 4 oder 6 zu Stapeln zusammen schieben. :)
    Wer es nicht glaubt, soll es einfach probieren. Passieren kann, nach meiner Erfahrung, nichts schlimmes.



    Was ist das denn für ein "unerwartetes Verhalten"?

    Beispiel:
    Man hat einen Stapel aus 3 Schnittmarken. Aussehen tut der aber, als ob es eine ganz normale Marke ist.
    Wenn man jetzt versucht die Marke mit 4 oder 6 zu verschieben, erwartet man, dass man einfach die Marke verschiebt.
    Das passiert aber nicht, sondern man "zieht" eine der Marken aus dem Stapel und man erhält einen SeamlessCut und eine zusätzliche Marke.


    Als mir das das erste Mal passiert ist, hat mich das schon ziemlich verwirrt. Erst nach einen Blick in die marks war mir dann klar, dass ich wohl versehentlich mehrere Marken gestapelt hatte.
    Da sie Frage jetzt sicher aufkommt: Wie das Stapeln genau passiert war kann ich nicht sagen. Ich war dabei ein paar sehr kurze Schnipsel für Testzwecke aus eine Aufnahme zu schneiden, da muss ich mich beim zurecht schieben der Marken wohl verdrückt haben oder FB hat geprellt oder was auch immer...



    - Mit diesem Patch funktioniert das in 2.1.8 eingeführte "Skip edited parts" (aka "playjump") nicht mehr.

    Als ich den Patch vor einer Woche gemacht hatte, habe ich es noch gegen die 2.1.7 verglichen und da hat sonst nichts die GetNextBegin /End Funktionen verwendet.
    Ich hatte meinen gepatchten VDR jetzt auch eine Woche in produktiven Einsatz und auch keine Probleme mit dem (originalen) jumpplay.


    Ich hab mir das eben mal kurz angesehen und sehe jetzt aber eigentlich keinen Grund, warum das mit dem "Skip edited parts" nicht gehen sollte.
    Im dümmsten Fall würde ich eine Unsauberkeit am Übergang erwarten. ?(


    Da ich bei dem konkreten Problem keine DVB-Hardware zu Testen brauche, kann ich mir das die Tage aber auch mal ansehen.



    - Wenn aus einer Aufnahme nur ein einzelnes Stück rausgeschnitten wird, enthält die geschnittene Fassung eine Schnittmarke am Anfang (das wurde in Version 1.7.32 absichtlich geändert, so daß in einem solchen Fall *keine* Schnittmarken vorhanden sind).

    Ich denke mal, das müsste diese Geschichte sein:

    Code
    1. }
    2. fileSize += Length;
    3. // Generate marks at the editing points in the edited recording:
    4. - if (numSequences > 1 && Index == BeginIndex) {
    5. + if (numSequences > 0 && Index == BeginIndex) {
    6. if (toMarks.Count() > 0)
    7. toMarks.Add(toIndex->Last());
    8. toMarks.Add(toIndex->Last());

    Wenn das so beabsichtigt war, sollte sich die Änderung einfach raus nehmen lassen, ohne den Rest zu stören.


    Versucht habe ich das allerdings nicht, da ich das zuerst auf den Stand vor 1.7.32 geändert hatte. Ich hatte da noch nicht raus, das das Verschwinden der Schnittmarken unterschiedliche Ursachen hat.



    Daß aufeinanderliegende Schnittmarken "verschwinden", wenn eine geschnittene Aufnahme nochmal geschnitten wird, ist wohl verschmerzbar. Typischerweise wird eine Aufnahme ja nur *einmal* geschnitten und das wars dann.

    Ja, bei mir typischerweise auch.


    Es kommt aber ab und an mal vor, dass man mal 2 Aufnahmen aus einer heraus schneiden muss. Da schneide ich halt einfach mehrmals. Das reicht als Lösung für die 2-3 Mal im Jahr wo ich das brauche.
    Das es mir schon nach einem Monat aufgefallen ist, ist echt Zufall, ich hatte gerade so eine Aufnahme, das hätte auch länger deutlich dauern können.

    Gruss
    SHF



  • Der SeamlessCut muss im Zusammenhang mit dem neuen Cutter, der die Übergänge korrigiert, eingeführt worden sein oder kurz davor.
    Das ist, wenn zwei Sequenzen direkt aufeinander stossen. Das heisst die Schnittmarken sind auf der selben Position.
    Der SeamlessCut ist also ein Schnitt, der eigentlich keiner ist und auch nicht korrigiert werden muss.


    Das stimmt nicht so ganz. Der "seamless cut" ergab sich aus der Situation, daß man zwei Aufnahmen ein- und derselben Sendung hat, wobei jede nur einen Teil davon beinhaltet. Also z.B. beginnt die Sendung in der ersten Aufnahme und endet in der zweiten, und es gibt einen Bereich, der in beiden Aufnahmen enthalten ist. Dann kann man die beiden TS-Dateien in *ein* Recording-Verzeichnis kopieren (ggf. umbenennen, also 00001.ts und 00002.ts), den Index neu berechnen und dann an einem Frame in dem Übergangsbereich schneiden. Da die Daten ja vollkommen identisch sind muß auch nichts korrigiert werden und es ergibt sich ein "nahtloser" Übergang.


    Wenn einfach nur zwei Schnittmarken in einer Aufnahme an der gleichen Position liegen, dann wird dort beim Schneiden gar nichts gemacht.


    Klaus

  • O.k. dann ist der "seamless cut" also ein ganz spezieller Sonderfall.
    Ich hatte das in der HISTORY so interpretiert, dass es generell ein Schnitt gemeint ist, bei dem die Teile nahtlos passen.


    Wenn einfach nur zwei Schnittmarken in einer Aufnahme an der gleichen Position liegen, dann wird dort beim Schneiden gar nichts gemacht.

    Meine Änderung sorgt dafür, dass jetzt auch dieser Fall, im Falle eines Cut-Out, als "seamless cut" erkannt wird.
    Was mir noch immer als Sinnvoll erscheint, weil der Cutter sonst ja nichts vom Schnitt mitbekommt und keine Marken setzen kann.



    Zum Testen bin ich heute leider nicht mehr gekommen, habe mir Stelle im dvbplayer vom 2.1.18 aber noch mal genauer angesehen und kann mir inzwischen nicht vorstellen, das ich mit dem Problem bei "Skip edited parts" nichts zu tun habe:
    Vor meiner Änderung hat marks.GetNextBegin(m) (#494) immer einen Wert > m (oder 0) geliefert. Mit meiner Änderung kann der Wert jetzt auch gleich m sein.
    Dieser Fall wird etwas weiter unten bereits abgefangen:

    Code
    1. (#504) if (Setup.SkipEdited && Index > readIndex) {
    2. isyslog("skipping from %d (%s) to %d (%s)", readIndex - 1, *IndexToHMSF(readIndex - 1, true, framesPerSecond), Index, *IndexToHMSF(Index, true, framesPerSecond));
    3. readIndex = Index;
    4. CutIn = true;
    5. }

    An so einem Punkt wird also nach wie vor kein Schnitt erkannt. Es läuft so durch, als ob da keine Marke wäre und so ist es doch erwünscht.


    Und an den Stellen, wo gesprungen werden muss, müssen die Marken noch immer zuverlässig geliefert werden, sonst würden die ja auch im Cutter fehlen.

    Gruss
    SHF


  • Ich habe da jetzt eine Weile drüber gebrütet und auch einiges ausprobiert. Meine Vermutung, daß damit das "Skip edited parts" nicht mehr ginge, hat sich als falsch erwiesen. Da muß wohl irgend etwas anderes schiefgegangen sein, ich konnte es auch nicht reproduzieren. Daß Marken, die genau an der gleichen Stelle sitzen, beim nochmaligen Schneiden einer bereits geschnittenen Aufnahme erhalten bleiben, ist sehr schön, weil dann die Schnittinformation nicht verloren geht. Alles in allem sehe ich in deiner Änderung nur Vorteile, zumal der Code dann auch genau dem im Header beschriebenen Verhalten entspricht ;-). Ich werde sie also für die 2.1.9 übernehmen.


    Den ersten Teil allerdings werde ich weglassen, denn wenn es in einer Aufnahme keinerlei Schnittstellen gibt, dann braucht auch keine Schnittmarke ganz am Anfang zu sein.


    Klaus

  • Ich habe da jetzt eine Weile drüber gebrütet und auch einiges ausprobiert. Meine Vermutung, daß damit das "Skip edited parts" nicht mehr ginge, hat sich als falsch erwiesen. Da muß wohl irgend etwas anderes schiefgegangen sein, ich konnte es auch nicht reproduzieren.

    Ich denke, ich weiss, was du da hattest. Da ist bei mir nämlich auch was komisches aufgetreten.


    Wenn ich einen CutOut mit 4 nach vorne schiebe und dann gleich mit 8 überprüfen will, läuft die Wiedergabe weiter bis zur alten Position der Schnittmarke und springt erst dann.
    Das passiert aber nur so lange, bis man die Wiedergabe beendet (evtl. auch nur eine Zeit lang ???). Wenn man nach dem beenden die Wiedergabe erneut startet, springt er an der korrekten Stelle.


    Das habe ich jetzt mit einem vanilla VDR 2.1.8 nur mit den folgenden Patches nachstellen können.

    Code
    1. vdr-2.1.8-binaryskipstrict.diff
    2. vdr-2.1.8-editrecordingremovename.diff
    3. vdr-2.1.8-eit-memleak-v1.diff
    4. vdr-2.1.8-scheduleswitchblue.diff
    5. vdr-2.1.8-scheduleswitch.diff
    6. vdr-2.1.8-skipeditedresume.diff

    Die Änderungen aus diesem Thread sind noch nicht drin!


    Das Gleiche tritt aber auch schon beim VDR 2.0.6 mit dem originalen Jumpplay-Patch auf. Da hatte ich es aber für eine Nebenwirkung, eines der vielen Patches aus dem YaVDR-Paket, gehalten.


    Ich werde sie also für die 2.1.9 übernehmen.

    Wow, damit hatte ich gar nicht mehr damit gerechnet.


    Du hättest immer gerne einen Patch per Mail, wegen Mailadresse usw.?
    Mache ich dann morgen fertig, ich muss jetzt erst mal ins Bett :gaehn.


    Den ersten Teil allerdings werde ich weglassen, denn wenn es in einer Aufnahme keinerlei Schnittstellen gibt, dann braucht auch keine Schnittmarke ganz am Anfang zu sein.

    Da stört mich nicht. Wenn ich gewusst hätte, dass das Absicht war, hätte ich es gelassen wie es war.

    Gruss
    SHF



  • Wenn ich einen CutOut mit 4 nach vorne schiebe und dann gleich mit 8 überprüfen will, läuft die Wiedergabe weiter bis zur alten Position der Schnittmarke und springt erst dann.
    Das passiert aber nur so lange, bis man die Wiedergabe beendet (evtl. auch nur eine Zeit lang ???). Wenn man nach dem beenden die Wiedergabe erneut startet, springt er an der korrekten Stelle.


    Klar, das muß es sein! Das cReplayControl und der cDvbPlayer haben jeweils eine eigene Liste der Schnittmarken, und eine Änderung in cReplayControl bekommt cDvbPlayer u.U. erst mit deutlicher Verzögerung mit. Ich muß mal überlegen, wie ich das einigermaßen sauber hinbekommen kann, daß die beiden mit der selben Liste arbeiten.


    Quote


    Das Gleiche tritt aber auch schon beim VDR 2.0.6 mit dem originalen Jumpplay-Patch auf. Da hatte ich es aber für eine Nebenwirkung, eines der vielen Patches aus dem YaVDR-Paket, gehalten.


    Die Situation dort war die gleiche wie jetzt.


    Quote


    Du hättest immer gerne einen Patch per Mail, wegen Mailadresse usw.?


    Das hängt davon ab, ob du in HISTORY und CONTRIBUTORS genannt werden möchtest. Ich liste nur Leute auf, die ihren Klarnamen und eine Email-Adresse angeben.


    Klaus

  • So, das ist jetzt hoffentlich die letzte größere Änderung vor der 2.2.0 ;-).
    Hiermit werden die Schnittmarken für den cDvbPlayer aus dem cReplayControl heraus gesetzt, so daß beide genau die gleiche Liste verwenden und der weiter oben beschriebene Effekt nicht mehr auftritt. Netter Nebeneffekt: "Skip edited parts" bzw. "Pause replay at last mark" muß nun nicht mehr bereits aktiviert sein, bevor die Wiedergabe gestartet wird.
    Vielleicht mögen ja einige das schon mal ausprobieren (vorherige Patches seit der 2.1.8 sind Voraussetzung, sonst passt dieser nicht - ansonsten halt von Hand anwenden), oder zumindest den Patch mal durchschauen und auf offensichtliche Fehler prüfen. Am Sonntag kommt dann die 2.1.9 mit allen bisherigen Änderungen, und dann haben wir noch eineinhalb Wochen Zeit um eventuelle letzte Problemchen auszubügeln.


    Klaus

  • Der Patch hat zwar wegen einer Kommentarzeile etwas gezickt und das obwohl ich alle bisherigen Patches drin hatte - denke ich.
    Im Endeffekt läuft es aber wie es soll :tup .


    Ich konnte das beschriebene Problem nicht nachstellen und auch sonst habe ich beim Testen in der Beziehung keine Ungereimtheiten feststellen können. Auch kommen, wenn man eine Aufnahme mehrfach schneidet, bis auf das zusätzliche % identische Aufnahmen raus.
    Ich würde also sagen, das passt so!
    Wirklich getestet habe ich aber bislang aber nur die Schnittgeschichte hier.


    Auch im Patch selber ist mir beim durchschauen nichts offensichtliches aufgefallen. Wobei ich da sagen muss, dass nicht so den Überblick habe um etwaige Auswirkungen an anderer Stelle beurteilen zu können.

    Gruss
    SHF