Bei USE_CUTTING gab's noch n kleines Problem mit dem setzen, wen das für vdrsync noch interessiert bitte nochmal downloaden - aber die meisten scheinen inzwischen eh ProjectX zu benutzen 
Burn 0.1.0 Public Beta bis -pre12 [alt]
- LordJaxom
- Geschlossen
-
Also ich weiß nich ob das so gewollt is...
May 10 21:41:32 hanvdr vdr: [4680] burn: progress 0
May 10 21:47:48 hanvdr vdr: [4680] burn: progress 0
May 10 21:47:56 hanvdr last message repeated 8 times
May 10 21:47:57 hanvdr vdr: [4680] burn: progress 0
May 10 21:48:03 hanvdr last message repeated 6 times
May 10 21:48:04 hanvdr vdr: [4680] burn: progress 0
May 10 21:48:05 hanvdr vdr: [4680] burn: progress 1
May 10 21:48:19 hanvdr last message repeated 14 times
May 10 21:49:32 hanvdr vdr: [4680] burn: process mplex (pid = 4714) exited gracefully (exit code 0)
May 10 21:49:32 hanvdr vdr: [4680] burn: process "mplex" exited
May 10 21:49:32 hanvdr vdr: [4680] burn: process ended: mplex
May 10 21:49:32 hanvdr vdr: [4680] burn: starting sh -c 'vdrburn-dvd.sh demuxpx' (pid = 4743)
May 10 21:49:32 hanvdr vdr: [4680] burn: starting sh -c 'vdrburn-dvd.sh mplex' (pid = 4744)
May 10 21:49:32 hanvdr vdr: [4680] burn: process demux (pid = 4713) exited gracefully (exit code 0)
May 10 21:49:32 hanvdr vdr: [4680] burn: process "demux" exited
May 10 21:49:32 hanvdr vdr: [4680] burn: process ended: demux
May 10 21:49:35 hanvdr vdr: [4680] burn: progress 25
May 10 21:49:36 hanvdr vdr: [4680] burn: progress 14
May 10 21:49:37 hanvdr vdr: [4680] burn: progress 14
May 10 21:49:38 hanvdr vdr: [4680] burn: progress 16
May 10 21:53:23 hanvdr vdr: [4680] burn: progress 16
May 10 21:53:37 hanvdr last message repeated 14 times
May 10 21:53:38 hanvdr vdr: [4680] burn: progress 17
May 10 21:53:58 hanvdr last message repeated 20 times
May 10 21:53:59 hanvdr vdr: [4680] burn: progress 18
May 10 21:54:20 hanvdr last message repeated 21 times
May 10 21:54:21 hanvdr vdr: [4680] burn: progress 19
May 10 21:54:46 hanvdr vdr: [4680] burn: process demux (pid = 4743) exited gracefully (exit code 0)
May 10 21:54:46 hanvdr vdr: [4680] burn: process "demux" exited
May 10 21:54:46 hanvdr vdr: [4680] burn: process ended: demux
May 10 21:54:46 hanvdr vdr: [4680] burn: process mplex (pid = 4744) exited gracefully (exit code 0)
May 10 21:54:46 hanvdr vdr: [4680] burn: process "mplex" exited
May 10 21:54:46 hanvdr vdr: [4680] burn: process ended: mplex
May 10 21:54:46 hanvdr vdr: [4680] burn: starting sh -c 'vdrburn-dvd.sh demuxpx' (pid = 4769)
May 10 21:54:46 hanvdr vdr: [4680] burn: starting sh -c 'vdrburn-dvd.sh mplex' (pid = 4770)
May 10 21:54:49 hanvdr vdr: [4680] burn: progress 31
May 10 21:54:50 hanvdr vdr: [4680] burn: progress 26Es scheint als ob der Fortschritt ausgewürfelt wird..
-
Hi , LordJaxom
Is nicht wahr > die pre11 brennt bei mir ne Dvd+rw.
Seh ich zum ersten Mal das Abbild erstellen und brennen klappt.
Thanks![:]](https://www.vdr-portal.de/images/smilies/pleased.gif "Freude")
Is ne Super Arbeit die du da hinlegst !EDIT:
SmartNavigation passt auch, und Chapters wurden ebenfalls alle 5Min. erstellt
(sowie vorgesehen).
Hab allerdings nur eine Aufnahme gewandelt, und nicht geshrinkt.
EDIT ENDE:Gruss Bert
-
Chapter funktioniert leider immer noch nicht.
-
dvd.xml....
ist nicht gepackt, einfach nur das .zip wegnehmen
cu hanker
-
Zitat
Originally posted by LordJaxom
Zum Wochenende gibts mal wieder ne Pre und am Wochenende hoffentlich dann die Final...Oh oh, ich komm mit meinem DMH-DVD und den mehreren counters im Moment noch net zu Rande, mal sehen, ob ich bis zum W-Ende etwas einigermaßen Abgeschlossenes bieten kann, was dann in die Final reinkommt. Vielleicht dann doch erstmal mit nur einem Counter...
-
hanker: Also die dvd.xml sieht eigentlich gut aus. Aber hast Du mal geschaut, wie lange die Filme wirklich sind? Ich habe mal in das dvd.log aus diesem Post geschaut und festgestellt, daß der Stream einige Fehler enthält, die ProjectX ausbügelt:
Code
Alles anzeigen[demux] 65 %!> dropping GOP# 3818 @ orig.PTS 07:22:11.043 (2387793951), errorcode: 24 [demux] !> Pics exp/cnt 11/10, inGOP PTS diff. 0ms, new Timecode 00:30:30.320 [demux] !> PTS difference of 43200 (00:00:00.480) to last exported GOP detected [demux] !> dropping useless B-Frames @ GOP# 3819 / new Timecode 00:30:30.320 [demux] 66 %!> dropping GOP# 3863 @ orig.PTS 07:22:32.643 (2389737951), errorcode: 24 [demux] !> Pics exp/cnt 12/11, inGOP PTS diff. 0ms, new Timecode 00:30:51.360 [demux] !> PTS difference of 43200 (00:00:00.480) to last exported GOP detected [demux] !> dropping useless B-Frames @ GOP# 3864 / new Timecode 00:30:51.360... und ...[demux] 41 %!> 2 frame(s) (48ms) inserted @ 00:30:41.664 [demux] !> 2 frame(s) (48ms) inserted @ 00:31:17.232 ... und ... [demux] 42 %!> 2 frame(s) (48ms) inserted @ 00:32:02.448 [demux] 43 %!> 2 frame(s) (48ms) inserted @ 00:32:32.976
und später kommt dann einCode[demux] /usr/bin/vdrburn-dvd.sh: line 33: 2770 Datenübergabe unterbrochen (broken pipe) cat "$MPEG_DATA_PATH/pjx.mpv" [demux] 2772 Gleitkomma-Ausnahme | requant $REQUANT_FACTOR >"$MPEG_TMP_PATH/vdrsync.mpv"Zu diesem Zeitpunkt hat dvdauthor 208MB geschrieben.
Das setzt sich dann fort bei der 2. Aufnahme (131MB und Gleitkomma-Fehler) und endet bei der 3. Aufnahme (128MB, Gleitkomma-Fehler) mit mehr Audio-Fehlern als bei den ersten beiden.
Danach sieht es also so aus, als ob requant abbricht ohne das Skript zu beenden und es werden dann nur gekürzte Titel mit insgesamt knapp 500MB gebrannt - was auch die Konvertierungsgeschwindikeit erklären würde
dvdauthor setzt in diesem Fall halt die Kapitel so weit wie der Film reicht, also z.B. bei 10 und 20 min wenn der Film 26 min lang ist.FireFly
-
Hallo zusammen!
dmh:
Gibt es von Deinem DMH-DVD-Archiv-Patch schon eine aktuelle "Zwischenversion" ? Im burn-CVS konnte ich leider nichts finden.
Ich hatte früher Deine erste Version des Patches für das alte burn-plugin im Einsatz, und nun warte ich sehnsüchtig auf die "Fortsetzung" von Dir
Ich schrecke auch nicht vor Betatesting zurück
-
FireFly:
Wenn Du Aufnahmen hast die bei requant nachvollziehbar an bestimmten Stellen die FPEs werfen, dann versuch doch mal ein Corefile zu bekommen und auszuwerten (kannst Du das? Irgendwo im WIKI gab's ne HOWTO dafür), vielleicht kann ich mit den Infos dann gleich requant fixen
Wie sieht sich das eigentlich mit tcrequant aus? Gleiche Aufrufart, einfach zu ersetzen?
-
-
Zitat
Wenn Du Aufnahmen hast die bei requant nachvollziehbar an bestimmten Stellen die FPEs werfen ....
.. habe ich "leider" nicht - das Log war ja von hanker. Vielleicht kann er's??
Ich habe hier nur Aufnahmen von SWR RP, die mit Project X asynchron werden - vdrsync.pl kanns aber
Wenn möglich sollte man also von SWR BW anstatt SWR RP aufnehmen, aber ups, das wird jetzt doch etwas offtopic. -
Hallo LordJaxom,
vielen Dank für das super Plugin. Wenn ich mir ein Plugin mit auf die VDR-Insel nehmen dürfte, wäre meine Wahl das burn-PlugIn.
Die Cut-Funktion finde ich ebenfalls sehr hilfreich. Da ich jetzt auch ProjectX (Version 0.90.4.00) nutze hier mal meine Erfahrungen:
Das Skript marks2bytepos.pl ist meines Erachtens nicht mehr nötig. Habe mehrere Filme mit der Option
Code$JAVA_HOME/bin/java -Djava.awt.headless=true \ ... -cut $RECORDING_PATH/marks.vdr \ ...
in der vdrburn-dvd.sh gebrannt. Funktioniert hier bestens. ProjectX liest die vdr-marks also bereits korrekt aus. Wäre super, wenn man das auch einbauen könnte. Aber ich denke, da ist FireFly dran...Außerdem wäre (wenn schon die Cut-Funktion benutzt wird) ein Analysieren der Aufnahmen per vdrsync.pl mit der Option "-cut" sinnvoll um die korrekte Größe zu ermitteln. Bei mir in jobs.c, Zeile 77:
Codestring command = format("vdrsync.pl -i -cut '{0}'") % m_fileName;
Vielleicht kannst Du damit ja was anfangen... Jedenfalls ein dickes Dankeschön für Deine Arbeit!caps!
-
-
Meistens so um die 3-4GB, aufgeteilt bei 2GB... Gibt's da Fehler, wenn die .vdr-Dateigröße über 2GB geht?
-
Bei mir hat das Schneiden mit mehreren vdr-Dateien irgendwie mal nicht richtig geklappt, deshalb bin ich von Timecode auf Bytepos umgeschwenkt und habe für die Umrechnung das marks2bytepos.pl geschrieben. Ich werde das aber noch mal testen (mit der 0.90.4.0), vor allem mit mehreren Files kleiner 2 GB
-
-
Oh...
Schon wieder was gelernt. Na dann seh ich für die cut-Option in ProjectX keine Probleme. Habe auch mehrere Filme auf eine DVD gepackt usw.
-
ZitatAlles anzeigen
Originally posted by amicus
dmh:Gibt es von Deinem DMH-DVD-Archiv-Patch schon eine aktuelle "Zwischenversion" ? Im burn-CVS konnte ich leider nichts finden.
Ich hatte früher Deine erste Version des Patches für das alte burn-plugin im Einsatz, und nun warte ich sehnsüchtig auf die "Fortsetzung" von Dir
Ich schrecke auch nicht vor Betatesting zurück
Ich werde mich heute nachmittag da wohl mal dran setzen und eine lauffähige Version schnüren. Zu finden im Moment nur auf meinem VDR, dann müsstest Du Dich da schon reinhacken...
-
Zitat
Original von dmh
Ich werde mich heute nachmittag da wohl mal dran setzen und eine lauffähige Version schnüren. Zu finden im Moment nur auf meinem VDR, dann müsstest Du Dich da schon reinhacken...
Ok, moment kurz...
Nee, Späßle..Ok, dann warte ich bis heute abend, hoffentlich klappts.
Danke schonmal im Vorraus! -
Hallo, da bin ich wieder
Ich habe mal einige kleine Sketche zu einer VDR-Aufnahme zusammenkopiert und nen neuen Index generiert:Code-rw-r--r-- 1 vdr video 76018039 Apr 7 20:54 001.vdr -rw-r--r-- 1 vdr video 15855982 Mar 29 2004 002.vdr -rw-r--r-- 1 vdr video 60517597 Feb 29 2004 003.vdr -rw-r--r-- 1 vdr video 13219858 Apr 14 2004 004.vdr -rw-r--r-- 1 vdr video 60080 May 11 15:22 index.vdr
Schnittmarken mit VDR gesetzt:Code# cat marks.vdr 0:02:01.10 0:02:42.20 0:04:32.21 0:04:58.10
und das ganze dann mit PX Timecodes gedemuxt (<- steht das Wort schon im Duden? :D)Codesummary of created media files: .Video (m2v): 629 Frames 00:00:25.160 '/mnt/vdr/tmp/001.mpv' Audio 1 (ac3): 786 Frames 00:00:25.152 0/0/0/0 '/mnt/vdr/tmp/001.ac3' Audio 2 (mp2): 1048 Frames 00:00:25.152 0/0/0/0 '/mnt/vdr/tmp/001[1].mpa' => 9.020.032 bytes written...Dann habe ich mit marks2bytepos.pl die marks.vdr konvertiert:
Code# marks2bytepos.pl . >px.cut # cat px.cut 0076018039 0091705013 0152391618 0164493421und das ganze nochmal laufen lassen:
Codesummary of created media files: .Video (m2v): 1661 Frames 00:01:06.440 '/mnt/vdr/tmp/001.mpv' Audio 0 (ac3): 2076 Frames 00:01:06.432 0/0/1/0 '/mnt/vdr/tmp/001.ac3' Audio 1 (mp2): 2768 Frames 00:01:06.432 0/0/2/0 '/mnt/vdr/tmp/001.mpa' => 27.549.140 bytes written...Ergenbis: beim ersten Lauf mit Timecodes fehlt einiges, beim zweiten Lauf mit Bytecodes entspricht das Ergebnis den gewünschten Ausschnitten. (Wer's nicht glaubt kann ja die geschnittene Länge anhand der marks.vdr nachrechnen ;D) Für mich sieht das so aus, dass PX jede Datei mit 2000MB erwartet, wofür auch die Schnittanzeige im PX-GUI spricht. Bei kleineren vdr-Files geht's dann schief (und die werden z.B. erzeugt wenn die Platte grade volläuft :]) Vielleicht habe ich auch was falsch gemacht, aber was? Es war die gleiche Kollektion mit den gleichen Parametern außer dem Schnittmodus. Kann das vielleicht noch jemand verifizieren?
Hat jemand Lust PX zu debuggen und korrigieren? Ich habe mal reingeschaut, blicke bei Java aber ganz und gar nicht durch
Oder bleiben wir lieber beim Wörg-ehraund mit Bytecodes?FireFly
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!