[ANNOUNCE] Cut-a-Lot 0.0.2

dmh · 13. September 2006

Für heute abend habe ich keine Lust mehr, auch nicht, die History ins Deutsche zu übersetzen. (Also, wenn sich jemand daran versuchen möchte, bitte gerne).

Im Anhang gibt's die neue Version.

Kurze Beschreibung: Schneidet eine Aufnahme in mehrere Aufnahmen anhand von benannten Schnittmarken.

Aus der History:

Zitat

2006-09-12: Version 0.0.2

- Added setup option to choose whether to adjust starting time of a recording to
its original starting time or not - based on a "compensate start time on
cutting"-patch by Udo Richter (Suggested by vejoun@vdr-portal)

- Added Plugin-Service "Cutalot-MultiCut-v1.0" (Suggested by vejoun@vdr-portal)

- Now gap finder always creates a cutting mark on the first and last frame which
completely recovers a deleted marks.vdr according to cut out parts (Suggested
by vejoun@vdr-portal)

- Now after Multi-cut finished one recording invoke-user-command is executed
with the parameter "multi-cut" (Suggested by vejoun@vdr-portal)

- Added setup option to choose whether to add cutting prefix (%) to cut
recordings or not (Suggested by vejoun@vdr-portal)

Alles anzeigen

Viel Spaß beim Ausprobieren.

DMH

EDIT: Version 0.0.2a mit Bugfixes gibts weiter unten im Thread.

vejoun · 13. September 2006

Hallo,

Ein kleines Problemchen, mein VDR kennt kein GetLast:

Code

g++ -O2 -Wall -Woverloaded-virtual -fPIC -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"cutalot"' -I../../../include cal-gapmarker.c
cal-gapmarker.c: In constructor 'cCalGapMarkingThread::cCalGapMarkingThread(const char*, int)':
cal-gapmarker.c:48: error: 'class cIndexFile' has no member named 'GetLast'
make: *** [cal-gapmarker.o] Fehler 1

dmh · 13. September 2006

Danke für den Hinweis. Ich habe nicht gesehen, dass diese Methode nur mit dem BigPatch zur Verfügung steht. Hab's jetzt schon geändert. Denke heute kommt die 0.0.2a. Die bekommste aber jetzt noch nicht, da ich auch noch eine Fehler gefunden habe.

Aber Du kannst auch einfach selbst Hand anlegen. Ändere doch in der cal-gapfinder.c die Zeile 48 zu:

Code

marks.Add(index->GetNextIFrame(index->Last(), false));

Dann sollte es kompilieren...

vejoun · 13. September 2006

Ja, jetzt geht's.

Zwei Kleinigkeiten sind mir aufgefallen.

1. Wenn man eine Aufnahme ein zweites Mal schneidet, entfernt VDR normalerweise vorher den ersten Schnitt. cutalot hangt den zweiten Schnitt an den ersten an.
cutalot sollte auch wie VDR den ersten Schnitt vorher entsorgen.

2. cuttime. Macht nur Sinn wenn die zu schneidende Aufnahme noch ungeschnitten ist.
Schneide ich eine geschnittene, steht die wirkliche Aufnahmezeit ja gar nicht mehr zur Verfügung. Könntest Du die Optionen evtl. dahingehend erweitern:

cuttime: "Nein" / "Nur wenn Ursprung ungeschnitten (also ohne %)" / "Immer"

Wenn aber niemand "Immer" braucht (ich brauchs nicht), würde es reichen bei "Ja" cuttime nur zu verwenden wenn "Ursprung ungeschnitten (also ohne %)" ist.

dmh · 13. September 2006

Zitat

Original von vejoun
1. Wenn man eine Aufnahme ein zweites Mal schneidet, entfernt VDR normalerweise vorher den ersten Schnitt. cutalot hangt den zweiten Schnitt an den ersten an.
cutalot sollte auch wie VDR den ersten Schnitt vorher entsorgen.

Jo, stimmt.

Zitat

Original von vejoun
2. cuttime. Macht nur Sinn wenn die zu schneidende Aufnahme noch ungeschnitten ist.
Schneide ich eine geschnittene, steht die wirkliche Aufnahmezeit ja gar nicht mehr zur Verfügung.

Ich habe mir schon überlegt nicht eben die Index-Datei als Grundlage zu nehmen, sondern die PTS. Denn nehmen wir mal an, dass VDR in einer Aufnahme mal 10 Minuten irgendwie abgeschmiert ist, dann sind die Indizes nahtlos und nach dem Crash stimmt die Zeit dann auch nicht mehr. Wenn man davon ausgeht, dass VDR korrekt startet, könnte man die erste PTS als Nullwert nehmen und dann alle anderen PTS entsprechend in vergangene Zeit umrechenen. Dann könnten auch nach beliebig vielen Schnitten immernoch die korrekte Zeit angezeigt werden. Dann müsste allerdings stets die Annahme gelten, dass VDR zumindest immer korrekt startet und dass die locale Uhr zumindest minutengenau geht. Mal sehen, was sich da so machen lässt.

Ich hatte eh mal angedacht, dass es beim Setzen der Schnittmarken interessant wäre, die zu dem Zeitpunkt aktuelle Uhrzeit anzuzeigen. Also wenn eine Aufnahme um 20.05 Uhr startet und man dort eben nicht 0:00:00.01 anzeigt sondern 20:05:00.01. Das hätte zum Beispiel den Vorteil, dass man dann mal nach 20.45 Uhr springen könnte (wenn bei den privaten meist der erste Werbeblock anfängt... ;))

vejoun · 13. September 2006

Zitat

Ich habe mir schon überlegt nicht eben die Index-Datei als Grundlage zu nehmen, sondern die PTS. Denn nehmen wir mal an, dass VDR in einer Aufnahme mal 10 Minuten irgendwie abgeschmiert ist, dann sind die Indizes nahtlos und nach dem Crash stimmt die Zeit dann auch nicht mehr. Wenn man davon ausgeht, dass VDR korrekt startet, könnte man die erste PTS als Nullwert nehmen und dann alle anderen PTS entsprechend in vergangene Zeit umrechenen. Dann könnten auch nach beliebig vielen Schnitten immernoch die korrekte Zeit angezeigt werden. Dann müsste allerdings stets die Annahme gelten, dass VDR zumindest immer korrekt startet und dass die locale Uhr zumindest minutengenau geht. Mal sehen, was sich da so machen lässt.

Das wäre natürlich das Sahnehäubchen. Meine vdr startet Aufnahmen immer sauber und dank ntp ist die Uhr Sekundengenau (mindestens ).

Zitat

Ich hatte eh mal angedacht, dass es beim Setzen der Schnittmarken interessant wäre, die zu dem Zeitpunkt aktuelle Uhrzeit anzuzeigen. Also wenn eine Aufnahme um 20.05 Uhr startet und man dort eben nicht 0:00:00.01 anzeigt sondern 20:05:00.01. Das hätte zum Beispiel den Vorteil, dass man dann mal nach 20.45 Uhr springen könnte (wenn bei den privaten meist der erste Werbeblock anfängt... ;))

Ich sag nur :wow. Das wäre :tup.

MarkusE · 13. September 2006

Hallo,

hier: clipinc: Start und Endzeiten optimieren gibt es ein Script, das die marks.vdr so erstellt, wie sie von Cut-a-Lot benötigt wird.
Das Script funktioniert nur im Moment nicht, weil Clipinc das Format geändert hat. Und ich habe keine Zeit, das zu anzupassen, weil wir Zwillinge bekommen haben ...

Markus

swer · 13. September 2006

Hallo

Ich habe das Programm noch nicht getestet aber hätte vielleicht eine Idee für eine Erweiterung.

Könnte man das Programm dahingehend erweitern das es in der Lage ist aus einer Aufnahme mehrere Zuschneidern, die aus unterschiedlichen nicht auf einander folgenden Segmenten bestehen.
Anwendungszweck wäre zum Beispiel bei den Anime Sendungen die auf Vox Laufen. Dort werden mehrere Folgen zu einer Sendung zusammen geschnitten. Nun würde ich gerne aus dem Intro dem Abspann und der jeweiligen Folge eigene Aufnahmen erstellen.

Als aus

A B C D E
|---|---|---|---|---|

wird
A B E
|---|---|---|
und
A C E
|---|---|---|
und
A D E
|---|---|---|

Weiss nicht ob es noch andere Anwendungsgebie dafür geben würde.

dmh · 13. September 2006

swer: Das so zu automatisieren, halte ich net für sinnvoll. Irgendwann soll auch mal ein Zusammenschneiden von zwei oder mehreren Aufnahmen ermöglicht werden. Dann könntest Du Dein Vorhaben in zwei Schritten realisieren: 1. Aufteilen der Sendung in die verschiedenen Teile, also A, B, C, D, E. (Das geht ja jetzt schon.) 2. Aneinanderschneiden von A, B, E, dann A, C, E, dann A, D, E.

Ich werde das auf jeden Fall mal im Hinterkopf behalten und beim Entwickeln des Mergers (Zusammenschneiders) dann berücksichtigen.

Ist echt schon spannend, welche (verrückten) Arten von Schneiden und Zusammenfügen von Aufnahmen es so gibt...

Urig · 14. September 2006

Zitat

Originally posted by vejoun
2. cuttime. Macht nur Sinn wenn die zu schneidende Aufnahme noch ungeschnitten ist.
Schneide ich eine geschnittene, steht die wirkliche Aufnahmezeit ja gar nicht mehr zur Verfügung. Könntest Du die Optionen evtl. dahingehend erweitern:

Wenn er hier noch so funktioniert, wie mein ursprünglicher Patch für VDR, ist das kein Problem: Die Startzeit wird um die Zeit bis zum ersten Cut-In verschoben. Schneidest du eine Aufnahme zwei mal, ist der Cut-In bei 0:00.01, und das verschiebt die Startzeit nicht nochmal. Schneidest du dagegen von der geschnittenen Version nochmal 5 Minuten vorne weg, wird die Startzeit auch um 5 Minuten weiter verschoben, und stimmt damit wieder.

Dinge, die zu einer falschen Startzeit führen können:
- Rundungsfehler. Gerundet wird auf 1 Minute.
- Verspäteter Start. Timer wurde nicht zur Anfangszeit aktiv, sondern erst später. (Manuell aktiviert, zu spät programmiert, durch andere Aufnahme blockiert)
- Lücken durch Empfangsstörungen oder durch vorherige Schnitte, wenn sie vor dem ersten Cut-In liegen.

Gruß,

Udo

vejoun · 14. September 2006

Urig

Ja, das funktioniert so. Aber:

Code

20:05                                                                 22:10
|--------------------------------------------------------|
   ^----------^       ^----------^          ^--------^           <- 1. Schnitt
   20:15     20:40    20:50     21:20      21:30   22:00


20:15                                 22:00
|----------||-----------|| ---------|
^---------^ <- 2. Schnitt
            ^----------^ <- 3. Schnitt

Der erste Schnitt ist ok. Der hat als Zeit 20:15.
Der zweite Schnitt auch. Zeit immer noch 20:15

Der dritte Schnitt aber bekommt als Zeit 20:40. Richtig wäre 20:50. Die Lücke müsste berücksichtigt werden. Das geht mit cuttime so nicht. Das meinte ich.
dmh's Lösung würde das berücksichtigen.

dmh · 14. September 2006

Zitat

Original von vejoun
dmh's Lösung würde das berücksichtigen.

Die funktioniert dann aber auch nur, wenn die erste PTS mit der richtigen Zeit verbunden wird. Es gibt also noch den Fall, wie urig bereits gesagt hat, dass aufgrund eines Timers mit höherer Priorität ein zweiter Timer bspw. erst 10 Minuten später anfängt. Dann ist die Startzeit nachwievor 20.05 Uhr, aufgenommen wurde aber erst 20.15 Uhr.

Mal gerade so eine dumme Idee: Könnte man zur Ermittlung des "richtigen" Beginns einer ungeschnittenen Aufnahme nicht den Datumszeitstempel der Datei 001.vdr nehmen? Diese Datei wird doch erst dann erstellt, wenn die Aufnahme tatsächlich beginnt. Und diese Uhrzeit würde ich dann der ersten PTS zuordnen.

jarny · 14. September 2006

Ich frag mich warum solche Informationen wie 'Programmierte Startzeit', 'Reale Startzeit', 'Original-Aufnahmedauer', 'Sendername' etc. nicht in der vdr.info drinstehen. Wäre bestimmt nicht schwer für KLS die ganzen Infos da reinzuschreiben. Tut keinem weh vom Speicherplatz-Bedarf aber wer die Infos braucht könnte sie sich an dieser zentralen Stelle auslesen.
Frag doch mal KLS ob er nicht die info.vdr-Datei ein bisschen aufbohren kann. Wäre bestimmt sauberer als das Datum aus dem Verzeichnisnamen oder der 001.vdr zu interpretieren.
Gruß
Jarny

vejoun · 14. September 2006

Das meiste steht ja schon drin.

Code

C S19.2E-1-1089-12020
E 31269 1157739300 12000 0 FF

Sender, Soll-Startzeit, Dauer. Programmierte Startzeit ist kodiert im Verzeichnisnamen. Fehlt einzig und allein die tatsächliche Startzeit.

Andererseits, warum ist die im Verzeichnis kodierte Zeit nicht die echte Startzeit? Das ist immerhin die Startzeit, die man im OSD sieht.

Wenn man einen 20:15 Film mit 5min Vorlauf aufnimmt, der aber aufgrund Prioritäten erst um 20:20 startet, sieht man im OSD trotzdem 20:10. Würde man hier 20:20 sehen, könnte man bereits im OSD erkennen, das etwas nicht stimmt. Jedenfalls was den Anfang angeht.

Nee, quatsch, wenn's so einfach wäre... Aber in die info.vdr würde es gut passen.

dmh · 14. September 2006

So, ich habe nun gerade mal eben meine VDR gepatcht und zwar so, dass eine Aufnahme immer die aktuelle Zeit zugewiesen bekommt und nicht die Startzeit der Sendung.

Wenn ich nun also (gerade läuft Charms auf Pro7, was um 15:59 Uhr laut EPG angefangen hat) aufneme, dann bekommt die Aufnahme eben nicht 15:59 Uhr zugewiesen sondern 16:29 Uhr (aktuelle Zeit).

Das ist doch sowieso generell besser, weil man da dann direkt sehen kann, dass etwas schiefgelaufen ist. Und dann stimmt die Anfangszeit auch mit der ersten PTS überein, vorausgesetzt die Systemuhr geht "richtig".

Gibt's Argumente, die gegen dieses Verfahren sprechen...?

By the way, das "Patchen" war auch nur eine Zeile in der records.c, also nicht spannendes oder aufwendiges.

vejoun · 14. September 2006

Ja, im Prinzip ist es einfach. Bis auf den Haken den ich mit "quatsch" meinte und den Du im Thread Soll-Zeit oder Ist-Zeit? Das ist hier die Frage... angesprochen hast. Wenn VDR zwischendurch unterbricht hat man anschliessend mehrere einzelne Teilaufnahmen... Das finde ich nicht so prickelnd.

Urig · 15. September 2006

Das die Aufnahme immer die Startzeit des Timers und nicht die tatsächliche Zeit verwendet, ist sinnvoll, da nur so eine Aufnahme zuverlässig fortgesetzt werden kann, zb. nachdem die Aufnahme manuell gestoppt und wieder gestartet wurde, oder falls ein VDR-Neustart erforderlich war. VDR funktioniert hier schlicht und deswegen zuverlässig: Existiert eine Aufnahme bereits, wird VDR immer die laufende Aufnahme an die vorhandene anhängen.

Zitat

Ja, das funktioniert so. Aber:

Ich sag ja, Lücken durch Empfangsstörungen oder durch vorherige Schnitte. Die Information, dass mitten in der Aufnahme mehrere Minuten fehlen, ist beim Schneiden verloren gegangen. Durch einen gründlichen Vergleich von PTS und index.vdr kann man die Lücken vermutlich rekonstruieren, aber: Ist das wirklich nötig? Wie oft schneidet man Aufnahmen wirklich mehrfach? Lohnt sich für so einen kleinen kosmetischen Fehler ein derart großer (und potenziell fehleranfälliger) Aufwand?

Gruß,

Udo

dmh · 15. September 2006

Zitat

Original von Urig
Durch einen gründlichen Vergleich von PTS und index.vdr kann man die Lücken vermutlich rekonstruieren, aber: Ist das wirklich nötig? Wie oft schneidet man Aufnahmen wirklich mehrfach? Lohnt sich für so einen kleinen kosmetischen Fehler ein derart großer (und potenziell fehleranfälliger) Aufwand?

Der Aufwand ist hier nicht wirklich groß. Das Auslesen der PTS eines I-Frames geht sehr einfach und schnell, wird unter anderem bei dem Lückenfinder schon eingesetzt.

Ich denke, dass ich das so (PTS anstelle von index) in der Version 0.0.3 mal implementieren werde. Ist wirklich keine derart große Sache. Dabei wird dann der erste PTS der Anfangszeit der Aufnahme zugeordnet und beim Schneiden entsprechend berücksichtigt. Dann muss halt jeder selbst sehen, wie er das mit der Anfangszeit einer Aufnahme handhabt.

Ich für meinen Teil finde die Geschichte mit der Ist-Zeit sehr gut. Ich kann so direkt sehen, ob etwas schiefgelaufen ist. Gibt es mehr als eine Aufnahme, so fand eine Unterbrechung statt, sei sie durch Prioritäten oder einen Crash hervorgerufen. Hat die Aufnahme eine andere Anfangszeit als im Timer eingestellt, so lief ebenfalls etwas schief. Find ich super und werde es mal eine Zeit lang testen...

dmh · 15. September 2006

Ein paar Bugfixes. Version 0.0.2a.

Auszug aus der History:

Zitat

- Now first deletes recordings with the same name as the cut recordings
(Suggested by Mike Constabel (vejoun@vdr-portal))

- Fixed adjusting starting time of recordings which don't have named cutting
marks

- Changed cIndexFile->GetLast to cIndexFile->Last() in order to compile without
BigPatch applied (Problem reported by Mike Constabel (vejoun@vdr-portal))

Alles anzeigen

Viel Spaß beim Test.

DMH

Urig · 16. September 2006

Hmmm, ich bin gespannt auf die praktischen Erfahrungen mit der PTS-Methode. Insbesondere, ob man sich auf die PTS dann auch verlassen kann, und es keine unerwarteten Sprünge gibt. Was passiert zb. wenn ich einen Timer stoppe und auf einen anderen Sender wieder fortsetze?

Gruß,

Udo

[ANNOUNCE] Cut-a-Lot 0.0.2

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema