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:

0:00:02.11
0:00:08.15
0:00:16.19
0:00:16.19
0:00:16.19
0:00:16.19
0:00:16.19
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.

Zitat von fnu

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.

Zitat von TheChief

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.

Zitat von kls

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...

Zitat von kls

- 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.

Zitat von kls

- 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:

}
          fileSize += Length;
          // Generate marks at the editing points in the edited recording:
-         if (numSequences > 1 && Index == BeginIndex) {
+         if (numSequences > 0 && Index == BeginIndex) {
             if (toMarks.Count() > 0)
                toMarks.Add(toIndex->Last());
             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.

Zitat von kls

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.

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.

Zitat von kls

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:

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

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.

Zitat von kls

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.

vdr-2.1.8-binaryskipstrict.diff
vdr-2.1.8-editrecordingremovename.diff
vdr-2.1.8-eit-memleak-v1.diff
vdr-2.1.8-scheduleswitchblue.diff
vdr-2.1.8-scheduleswitch.diff
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.

Zitat von kls

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.

Zitat von kls

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.

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 .

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.