Baustellen im Burn-Plugin

Ich liste hier mal alles gesammelt auf; in der Hoffnung, daß diese Probleme des für die meisten VDR-Systeme doch ziemlich zentralen Burn-Plugins Stück für Stück gelöst werden können:

Mit Schnittmarken ist es sich hier auch ins Gehege gekommen - vielleicht sollte deren Auswertung besser nicht voreingestellt sein, da man schon aus Speicherplatzgründen ja regelmäßig vorab direkt aus VDR-Menü/Aufnahmen schneiden wird.
Daher kann man dann in /usr/bin/vdrburn.sh setzen:
USE_CUT="${USE_CUT:-no}"
Allerdings scheint auch das nicht immer respektiert zu werden - bei einer vorab heftig geschnittenen Aufnahme kommt z.B. dennoch in der zugehörigen /tmp/.vdrburn.*/dvd.log (obwohl vdrburn/vdrsync eigentlich nach obiger Änderung vom Schneiden die Finger lassen sollte)...

Zitat

185 Mbytes of 185 readDEBUG Cut detected at 2112350890 before GOP 850

CUT detected in Video at 2112350890 before GOP 850
DEBUG ::1939248490::10200__NEW__2112350890
DEBUG Found non processed cuts in the buffer
DEBUG processing Cut at GOP 850
DEBUG Delaying processing cause cut is at the buffer end: 850, and start is 843

96049 PES packets processed
DEBUG Cut detected at 2112350890 before GOP 850

CUT detected in Video at 2112350890 before GOP 850
DEBUG ::1939248490::10200__NEW__2112350890
DEBUG Found non processed cuts in the buffer
DEBUG processing Cut at GOP 850
DEBUG Processing cut: ::1939248490::10200, 2112350890
DEBUG Setting cutcounter to 3

Start Sync failed for stream c0 while trying to drop Frames until 2112350890
cutlist: 1897128490::1898381290::348
cutlist: 1902312490::1903349290::636
cutlist: 1904818090::1939248490::10200
cutlist: 2112350890::2112368890::10205
syncing start of chunk 3 in c0 failed

Alles anzeigen

...und in /var/log/messages entsprechend:

Zitat

Dabei werden im Verzeichnis der VDR-Dateien zusätzlich size.vdr und size_cut.vdr angelegt, d.h. von vdrsync.pl eindeutig ein Schnitt versucht, wo es längst nichts mehr zu schneiden gibt.

Weiterhin müssen bei DVDs (anders als für Archiv-Disks) zur Einhaltung der Kapazitätsgrenzen die korrekten (3%-)Wachstums- und ggf. Requantisierungsfaktoren berücksichtigt werden - da scheinen sich noch Fehler zu verstecken, die vielleicht jemand, der sich mit diesem Plugin besser auskennt, bereits behoben hat.

Mit Hinzukommen von AC3 und der weiteren Erhöhung der Datenraten in den öffentlich-rechtlichen Sendern (ca. seit Weihnachten 2005 - oft sogar für einzelne Filme DL-Rohlinge erforderlich!) beschwert sich vdrsync.pl auch über folgendes:

Ist mir momentan nicht klar, wie das zu beheben ist (vgl. auch die Ausführungen insbesondere zu Gen2VDR-1.0-rc4 im HTPC-Forum...
Die weitere Kommentierung und ggf. Korrektur muß ich den echten Experten für dieses Plugin und vdrsync überlassen.

Auch bei u.a. FIFO-Nutzung und Zeichensatz gibt es noch Optimierungsmöglichkeiten.

Regelmäßig bleiben die temporären /tmp/.vdrburn.*/VDRSYNC.*/movie.mpg auch dann noch auf der Festplatte liegen, wenn sie bereits erfolgreich in /tmp/.vdrburn.*/DVDAUTHOR/*.VOB umgewandelt worden sind - was jeweils einen um mehrere Gigabyte überhöhten Speicherplatzbedarf zur Folge hat.

Außerdem scheint der Automounter nicht automatisch ausgeschaltet zu werden:
[quote]Jan 6 13:00:35 [kernel] cdrom: This disc doesn't have any tracks I recognize!
- Last output repeated 1434 times -

Alles anzeigen

Man kann sich natürlich darüber streiten, ob es die Aufgabe des Burn-Plugins ist, diesen beim Start zu de- und nach dem Brennen zu re-aktivieren (wahrscheinlich schon, wo denn sonst...) - "your thoughts?"

Zitat

Original von TEN
Mit Schnittmarken ist [das Burn-Plugin] sich hier auch ins Gehege gekommen - vielleicht sollte deren Auswertung besser nicht voreingestellt sein, da man schon aus Speicherplatzgründen ja regelmäßig vorab direkt aus VDR-Menü/Aufnahmen schneiden wird.
Daher kann man dann in /usr/bin/vdrburn.sh setzen:
USE_CUT="${USE_CUT:-no}"
Allerdings scheint auch das nicht immer respektiert zu werden - bei einer vorab heftig geschnittenen Aufnahme kommt z.B. dennoch in der zugehörigen /tmp/.vdrburn.*/dvd.log (obwohl vdrburn/vdrsync eigentlich nach obiger Änderung vom Schneiden die Finger lassen sollte)...

...und in /var/log/messages entsprechend:

Dabei werden im Verzeichnis der VDR-Dateien zusätzlich size.vdr und size_cut.vdr angelegt, d.h. von vdrsync.pl eindeutig ein Schnitt versucht, wo es längst nichts mehr zu schneiden gibt.

Folgendes fällt mir auch häufiger auf:

[...]
logger: Starting <nice -n 19 vdrsync.pl -o /tmp/.vdr-burn.vaLVfM/VDRSYNC.1 /video/Die_Geschnittenen/2006-01-09.00.40.99.99.rec>
Parameter validation not complete yet
Initialising and analysing the streams....


  10 Mbytes of 2365 read
[...]
 800 Mbytes of 2365 readDEBUG Cut detected at 2979892175 before GOP 4448


CUT detected in Video at 2979892175 before GOP 4448
DEBUG ::2963648975::53376__NEW__2979892175
DEBUG Found non processed cuts in the buffer
DEBUG processing Cut at GOP 4448
DEBUG Delaying processing cause cut is at the buffer end: 4448, and start is 444
3
DEBUG Found non processed cuts in the buffer
DEBUG processing Cut at GOP 4448
DEBUG Processing cut: ::2963648975::53376, 2979892175
DEBUG Setting cutcounter to 1


 810 Mbytes of 2365 read
[...]
1370 Mbytes of 2365 readDEBUG Cut detected at 3129666575 before GOP 7618


CUT detected in Video at 3129666575 before GOP 7618
DEBUG ::3116836175::91416__NEW__3129666575
DEBUG Found non processed cuts in the buffer
DEBUG processing Cut at GOP 7618
DEBUG Delaying processing cause cut is at the buffer end: 7618, and start is 761
1
DEBUG Cut detected at 3129666575 before GOP 7618


CUT detected in Video at 3129666575 before GOP 7618
DEBUG ::3116836175::91416__NEW__3129666575
DEBUG Found non processed cuts in the buffer
DEBUG processing Cut at GOP 7618
DEBUG Processing cut: ::3116836175::91416, 3129666575
DEBUG Setting cutcounter to 2


1380 Mbytes of 2365 read
[...]
2365 Mbytes of 2365 read
 1410822 PES packets processed
Assuming final sync for stream c0, cause there is no new chunk_start


Finished processing /video/Die_Geschnittenen/2006-01-09.00.40.99.99.rec/ 
No need to finish DVD Image, since there is none
Last fork ended for vdrsync.pl 15289

Da ist also überhaupt kein "-cut" mehr im Aufruf von vdrsync.pl - schneidet es trotzdem (behauptet es jedenfalls - "processing" geht wohl über einen reinen Hinweis hinaus), und wenn ja, warum?

# vdrsync.pl        


        VDRsync    Version 0.1.3PRE1-050322
[...]
        -cut
            cuts the recording according to the marks.vdr
[...]
    Cutting:
    vdrsync.pl /video/MyRecording/DATE/  -cut
[...]

Zitat

Original von LordJaxom
TEN: Die letzte vdrsync.pl-Ausgabe ist normal, er sagt Dir lediglich dass er einen Schnitt gefunden hat, nicht dass er selbst schneiden will.

Na ja, er sagt eben nicht nur "detected", sondern danach auch:

DEBUG Found non processed cuts in the buffer
DEBUG processing Cut at GOP 7618
DEBUG Processing cut: ::3116836175::91416, 3129666575

Gibt es für vdrsync denn irgendeine Notwendigkeit, überhaupt noch etwas mit den Schnitten zu machen, obwohl ihm die Kommandozeilenparameter sagen, sich darum gar nicht zu kümmern? Wenn VDR selbst schon geschnitten hat, müsste vdrsync ohne -cut doch eigentlich nur alles "am Stück" demultiplexen?

Zitat

Noad hat bei mir die Eigenart, bei fast jeder Aufnahme auf den letzten Frame ein In-Point zu setzen. Dann habe ich also eine Aufnahme mit zwei Werbeblöcken, die hat dann 7 Schnittpunkte (In, Out - Werbeblock - In, Out - Werbeblock - In, Out - Ende der Sendung - In). Hier schmiert vdrsync mir grundsätzlich auf der letzten Marke ab.
Abhilfe: Schauen ob die Aufnahme einen (ungeraden) Schnittpunkt am Ende hat, wenn ja entfernen und nochmal schneiden lassen.

Ich habe in mehreren Aufnahmen versucht, den letzten Schnittpunkt zu entfernen, und trotzdem steigt das burn-Plugin weiterhin aus.
Das Problem ist, es geht nicht um eine Entwickler-Testmaschine, sondern eine vielbeschäftigte Activy 300 (Gen2VDR-1.0-rc4) "außer Tastaturreichweite", auf die ich regelmäßig lediglich "aus der Ferne" über's Netzwerk per ssh komme - und wenn es oft nur unter solchen (kaum DAU-kompatiblen) Schwierigkeiten und mit unzähligen Anläufen möglich ist, die Festplatte in Richtung DVD+/-R leerzuräumen, gibt das "Tragödien im Wohnzimmer"...

Wenn es beim Debugging hilft, stelle ich gerne eine "Horror Disk" mit kurzen Aufnahmen als VDR-Dateien zusammen, die bei Aufnahme in ein Brennprojekt regelmäßig zum Abschmieren des burn-Plugins führen (die "Konkurrenz" vdrconvert ist gegenwärtig unter Gen2VDR wohl nicht "out of the box" lauffähig - aber wie gesagt, meine "Bastelmöglichkeiten" und Kenntnisse der Interna und Historie dieser Plugins sind momentan zu begrenzt, um in diesen erfolgreich auf weitere systematische Fehlersuche zu gehen) - und verschicke sie an die bei den (De)Muxing-/Mastering-/Brennroutinen aktiven (und vielleicht schon mit der Integration der oben bereits identifizierten Korrekturen befassten) Entwickler, durchaus auch einfach per Post...

Zur Not müsste man eben auch in burn auf ProjectX ausweichen, das nach entsprechenden Vorarbeiten ja auch ganz offiziell "kommandozeilenfähig ohne GUI" geworden ist - aber wenn ich selbst versuche, das Plugin darauf umzubiegen, würde dieses "Gehacke" bestimmt nur den z.B. von Dir wahrscheinlich gerade in Umsetzung befindlichen, ausgefeilteren Umbauten in die Quere kommen...

BTW, ein weiterer Punkt im burn-Plugin: Beim Editieren der Titel (Namen von Menüpunkten und DVD-Bezeichnung) fehlen (anders als beim Umbenennen mit 0 direkt unter "Aufnahmen") jeweils die Zahlen (0-9) in der Auswahl - nur so lange kein Problem, bis jemand z.B. "2001" aufnehmen wollte, gleich brennen will und es vom VDR nur als "arte - irgendwas" abgelegt bekommen hat.

Zitat

Original von LordJaxom
Wozu im Plugin rumhacken? Dafür gibts das Shell-Script...

/usr/bin/vdrburn.sh habe ich durchaus als Teil des Plugins (im Sinne "des Gesamtkunstwerks" ) gezählt - natürlich meinte ich diese Datei als Ort des Aufrufs von ProjectX, denn dort wird ja gegenwärtig auch vdrsync aufgerufen. Im in C geschriebenen Teil müsste man dann wohl lediglich die Auswahl des Demultiplexers (es gibt dann ja zwei) einfügen, die Problematik des "Wachstumsfaktors" 1.03 (nur) für VOBs (DVDs) überprüfen (alle VDR-Aufnahmen zusammen dürfen für eine 4.7 "GB"-DVD maximal ca. 4332 MB [bei 8.5 "GB" wären es 8060 "echte" MB] lang sein , weil sie sich beim De-/Remuxen um durchschnittlich fast 3% "ausdehnen" - soll irgendwo schon im Code stehen, wird gegenwärtig aber wohl doch noch nicht berücksichtigt), und die für Titel zur Verfügung stehenden Zeichen korrigieren (fehlende 0-9).

Vielleicht könnte man hier auch eine Einstellung zur Beschränkung der Brenngeschwindigkeit vorsehen und an das Shell-Skript übergeben (denn einige Brenner "übernehmen" sich hier: wie die Tests z.B. der c't zeigen, halten nur wenige aktuelle DVD-Rohlinge 16x wirklich so gut durch, daß hinterher etwas überall zuverlässig Lesbares herauskommt - und auch mancher VDR-PC stösst bei den geforderten Datenraten oberhalb von 4-8xDVD an seine Grenzen...).

Zitat

Da wollte ich ohnehin bitten dass mir da jemand mögliche (konfigurierbare!) Änderungen vorschlägt.

• ProjectX ist eine davon. Der letzte Stand ist wohl http://forum.dvbtechnics.info/showthread.php?t=2057&page=1#post14894 - eben über den Vorschlag, statt eines Dummy-X-Servers (wegen AWT) über die headless-Klassen zu gehen. (BTW, offenbar noch ein JAG-Fan...:D ).
• Ein Parameter für -speed= (bzw., falls auch cdrecord-ProDVD integriert werden soll, ggf. speed=) könnte hier wie oben ausgeführt aus den Plugin-Einstellungen übernommen werden.
• Bei den Schwierigkeiten von vdrsync sollte -cut jedenfalls keine Voreinstellung sein.

Zitat

Ich bin mir jetzt nicht so wirklich sicher ob es angekommen ist, deshalb erwähne ich es nochmal gesondert: Es genügt natürlich nicht, die letzte (ungerade) Schnittmarke nur zu entfernen. Selbstverständlich muss die Aufnahme danach erneut geschnitten werden, damit sich die Löschung der Schnittmarke auch auswirkt...

War schon klar, daß man erneut schneiden muß - sonst bleibt der MPEG-Strom, an dem sich vdrsync verschluckt, ja exakt derselbe wie zuvor.

Die Nachfrage betraf die "processing"-Meldungen - was vdrsync damit meint, wurde jetzt ja erläutert:

Zitat

Original von PeterD
vdrsync schneidet nicht sondern muss nur die "ausgefransten" ränder der schnitte von vdr korregieren.
Vdr macht nur den grobschnitt. Das ergebnis hat noch ein paar mpeg macken.
Der remultiplexer korregiert dann z.B die Die GOP sequenz und die PTS (program time stamps) im stream. Der schitt von vdr hinterlässt z.b. eine lücke im den time stamps.
Vdr kann das nicht allein.

Es hilft dann, die geschnittene Aufnahme mit geänderten Schnittmarken tatsächlich noch einmal neu zu schneiden - hat hier allerdings auch mehrere Anläufe gebraucht (und ich bin längst noch nicht mit allen Dateien fertig).

Das Umsetzen der Schnittmarken in VDR (bzw. die Erkennung am TV, wieviele und wo genau u.U. mehrere nahe beieinander oder an Anfang und Ende der Aufnahme liegende Marken gesetzt sind) ist aber gar nicht so einfach (sprich v.a. auch "wenig DAU-fest"), da durchaus häufig nach deren Entfernung die gesamte Aufnahme als roter Balken dargestellt, aber auf Länge 0 geschnitten wird.
Wenn es einen mir noch unbekannte Fernbedienungs-"Shortcut" geben sollte, die alle Schnittmarken entfernt und ohne Spulen/Springen und Verschieben zuverlässig (nur!) auf ersten und letzten Frame eine Schnittmarke setzt: dann schon vorab vielen Dank für den Hinweis darauf!
Da ist natürlich die Frage, was man an vdrsync selbst ändern könnte, um es etwas "toleranter" zu gestalten...