Hi, wilderigel
Thanks, habs auch grad gemerkt.
So gesehen funktioniert das nur brennen im BurnPlugin.
Gruss , Bert
Hi, wilderigel
Thanks, habs auch grad gemerkt.
So gesehen funktioniert das nur brennen im BurnPlugin.
Gruss , Bert
Hi , TEN
Das hier aus nem anderen Thread von dir;
Zweikanal-Tonspuren splitten: Kommandozeilenaufruf ProjectX, erweiterte vdrconvert/burn-Plugins?
hab ich auch im dvd.log festgestellt.
Gibts dazu ne Lösung oder ist das kein Probs?
Gruss , Bert
ZitatOriginal von Bert
Hier ist mal meine info.vdr
Wenn Du sie in [ code ] ... [ /code ] -Tags (ohne die Spaces) eingeschlossen postest, bleibt die Zeilenstruktur erhalten; wenn Du ein Archiv (z.B. .tgz) daraus machst, auf jeden Fall auch eventuelle Sonder- und Steuerzeichen.
Zitatdie /tmp/.vdr-burn.*/VDRSYNC.0/menu-bg-0.png
muss erst sehen wie ich die auf 50kb kriege, so das du auch noch was erkennen kannst,
denn immerhin ist die 548,1kb gross.
Da erscheinen ja mal alle Dashes korrekt.
Ohne größere Artefakte und ZIP (also direkt ansehbar) bekommst Du die Datei durch
...ergibt 2 Pixel pro Byte, zusätzlich verlustfrei geschrumpft durch Lauflängenkodierung.
Hi, TEN
Thanks für die Infos zum Bilder möglichst verlustfrei einfügen !
Sorry , zum Fehlschlag des diffs kann ich nix mehr sagen, denn ich habe jetzt das Verzeichnis burn-0.0.009 auf ne andere Maschine kopiert, und da frisch gepatcht.
Der diff ist da fehlerfrei durchgelaufen, wie folgt zu sehen.
blabla@PowerPc:~# cd /root/Desktop/one/burn-0.0.009
blabla@PowerPc:~/Desktop/one/burn-0.0.009# cat burn-0.0.009-TEN.diff | patch -p1
patching file common.c
patching file jobs.c
patching file jobs.h
patching file render.c
patching file scripts/vdrburn.sh
blabla@PowerPc:~/Desktop/one/burn-0.0.009#
Hier nochmal die info.vdr
Gruss , Bert
ZitatOriginal von Bert
Das hier aus nem anderen Thread von dir;
Zweikanal-Tonspuren splitten: Kommandozeilenaufruf ProjectX, erweiterte vdrconvert/burn-Plugins?
hab ich auch im dvd.log festgestellt.
Gibts dazu ne Lösung oder ist das kein Probs?
Sieht bloß erschreckend aus, schon der hohen Zahlen wegen...
!> error in pes_extension of pes-ID 0xC0 @ pos: 4300736 (596 / 20 / 37 / true / true)
!> error in pes_extension of pes-ID 0xE0 @ pos: 4303532 (2048 / 28 / 37 / true / true)
!> error in pes_extension of pes-ID 0xE0 @ pos: 4311560 (2048 / 28 / 42 / true / true)
!> error in pes_extension of pes-ID 0xC0 @ pos: 4315656 (596 / 20 / 37 / true / true)
-> more than 500 warnings/errors, stop logging..
Lösung ist aber "Ignorieren", ProjectX-Autor sagt, das ist kein Problem mehr (mit der wie oben beschrieben installierten, neuesten Version).
Würde mal hoffen, daß er in die nächste Version irgendein Loglevel-Feintuning einbaut, um diese Warnungen ggf. aus den Protokolldateien heraushalten zu können (und damit nicht sozusagen "seine 500 Fehler zu verbrauchen", bevor kritischere und möglicherweise interessante Meldungen auftauchen).
Man könnte natürlich auch die Beschränkung auf 500 Warnungen abschalten und alle solchen (oder auch leeren bzw. nur aus Zahl + Prozentzeichen bestehenden) Zeilen wegwerfen, z.B. per
Man könnte auch den Untertitel Patch aus dem VDR entfernen, falls der nicht benötigt wird.
Dann fallen die Tonnen an Warnmeldungen auch ned an.
Hi , TEN
ZitatAlles anzeigenSieht bloß erschreckend aus, schon der hohen Zahlen wegen...
code:
1:!> error in pes_extension of pes-ID 0xC0 @ pos: 4300736 (596 / 20 / 37 / true / true)
2:!> error in pes_extension of pes-ID 0xE0 @ pos: 4303532 (2048 / 28 / 37 / true / true)
3:!> error in pes_extension of pes-ID 0xE0 @ pos: 4311560 (2048 / 28 / 42 / true / true)
4:!> error in pes_extension of pes-ID 0xC0 @ pos: 4315656 (596 / 20 / 37 / true / true)
5:-> more than 500 warnings/errors, stop logging..
Lösung ist aber "Ignorieren",
Na dann bin ich ja beruhigt.
ZitatMan könnte auch den Untertitel Patch aus dem VDR entfernen, falls der nicht benötigt wird.
Dann fallen die Tonnen an Warnmeldungen auch ned an.
Is ne gute Idee !
Gruss , Bert
So, oben gibt's eine nochmals aktualisierte Diff-Datei zur Erstellung von burn-0.0.009-TEN - danke nochmals an alle Helfer & Tester!
Da schlummerten ja noch ein paar ziemliche Überraschungen im Code... u.a. sind folgende Macken behoben:
Folgendes ist noch nicht ganz perfekt, d.h. nicht endgültig gelöst:
Das ist ja alles sehr interessant!!!!
Leider steig' ich mangels Skript und C-Wissen nicht so ganz durch.
Zwei Fragen/ Anregungen:
1. Sehe ich das richtig, das auch die gepatchte Version nach dem Demuxen erst mit mplex muxt und dann mit dvdauthor das Video-DVD-Verzeichnis aufbaut? Könnte man das mit dem burn-Plugin in einem Schritt machen, in dem man eine Pipe benutzt? Das spart nach meiner Erfahrung nicht nur Platz, sondern geht auch schneller. Mit vdrsync geht das sogar komplett in einem Durchgang, mit ProjectX leider nicht, weil das zunächst die Dateien demuxt und dann in einem zweiten Schritt erst für die Synchronisation zwischen Bild und Ton sorgt.
2. Im Diff-File lese ich:
Bislang versteht sich ProjectX bei mir auf die Schnittmarken vom VDR ganz gut, aber warum ist die Verwendung der Schnittmarken den unnötig, wenn man ProjectX nimmt? Soll dieses Feature denn wegfallen?
ZitatOriginal von berndb
Leider steig' ich mangels Skript und C-Wissen nicht so ganz durch.
Das wirst Du nach ein, zwei Tagen mit den Quellen ganz anders sehen... Believe me, mehr Detailkenntnisse habe ich nämlich auch nicht - das ist mein allererstes diff & ANNOUNCE (und es kommt mir durchaus komisch vor, an einem Plugin herumzuschrauben, das bislang eigentlich ausschließlich die "Baustelle der Großen Gurus" war - aber diese Änderungen bringen IMHO einfach zu viel Stabilitäts- und Komfortgewinn, um sie lediglich auf meiner Festplatte zu verstecken).
Zitat1. Sehe ich das richtig, das auch die gepatchte Version nach dem Demuxen erst mit mplex muxt und dann mit dvdauthor das Video-DVD-Verzeichnis aufbaut? Könnte man das mit dem burn-Plugin in einem Schritt machen, in dem man eine Pipe benutzt?
"Man könnte" wahrscheinlich schon (einmal davon abgesehen, daß es sehr aufwendig zu formulieren wäre, z.B. wenn dabei Audiostreams gesplittet und beliebig viele Spuren berücksichtigt werden müssen, also eine unterschiedliche Zahl von Ein- und Ausgabedateien besteht), aber leider bleiben die Konstruktionen mit Pipes auf manchen Systemen immer wieder mal hängen - s.o. zu Helaus in MKISO_BURN bei Bert.
Das soll nicht heißen, daß es niemand ausprobieren und ggf. Änderungsvorschläge posten sollte (ganz im Gegenteil, die vdrburn.sh sind ja aus dieser Überlegung heraus in Volldarstellung mit Zeilennummern verlinkt!) - sondern nur, daß dies aus gutem Grund nicht Bestandteil einer Überarbeitung ist, die burn eigentlich "nur" wieder allgemein stabil lauffähig machen sollte (und zwar mit den seit einiger Zeit von vielen großen v.a. deutschsprachigen Sendern verwendeten Formaten wie AC3, "unsauber" umgeschaltetem 16:9, und in DVB eigentlich unsinnigem und für die DVD-Erstellung bislang schwer verdaulichem Zweikanalton kombiniert in nur einem Stereostream) - und bei der Gelegenheit noch ein paar Probleme der bisher verfügbaren Versionen zu beheben.
Zitat2. Im Diff-File lese ich:
Bislang versteht sich ProjectX bei mir auf die Schnittmarken vom VDR ganz gut, aber warum ist die Verwendung der Schnittmarken den unnötig, wenn man ProjectX nimmt? Soll dieses Feature denn wegfallen?
Braucht es ebenfalls nicht, es lässt sich ja anschalten (von mir jetzt zwar noch nicht persönlich getestet - aber wenn das Feedback hier ergibt, daß es -mit oder ohne weitere Änderungen- keine Probleme macht, spricht nichts dagegen).
Die Anmerkung bezieht sich auf folgenden Sachverhalt: Bei vdrsync.pl musste/durfte oft erst beim "SYNC" (Demultiplexen) geschnitten werden, weil es sonst aufgrund der schon im VDR vorgenommenen Schnitte (z.B. bei ungerader Zahl, d.h. aus schwer nachvollziehbaren bzw. kaum vermeidbaren Ursachen) plötzlich abschmierte. Das aktuelle ProjectX hingegen hat bislang jede bereits vorab im VDR geschnittene Aufnahme (was aus Speicherplatzgründen ja ganz sinnvoll ist) anstandslos demultiplexed, d.h. es scheint schlicht nicht mehr notwendig, den eigentlichen Schnitt zwangsläufig erst bis zum burn-Durchlauf aufzuschieben, also "nach hinten" in die "SYNC"-Phase zu verlegen.
Falls ProjectX eine Cut-Liste aus VDR zuverlässig übernimmt (was jemand bestätigen und ggf. optimieren sollte, der diese Workflow-Variante mit dem Schnitt erst bei "SYNC" bevorzugt), soll das durchaus eingebaut bleiben - dann muß (AFAICS nach Hinzufügen von $CUTCMD im Java-Aufruf) lediglich von no nach yes "der Schalter umgelegt werden".
Hallo,
Zitat
Danke erst einmal für Deine tolle Arbeit. Wollte die vollständige Update Methode benutzen, bekomme aber leider nur eine HTML-Seite als burn-0.0.009-TEN.diff. Wenn das diff auf dieser Seite gemeint ist, sollte oben 9839 und nicht 9824 stehen.
MfG
wino
Hi , TEN
Gute Arbeit
Hab nun das ;
Burn: AC3+Zweikanalton+16:9 mit ProjectX
umgesetzt.
Test ist grad fertig geworden, und ich meine das Menü sieht jetzt sehr gut aus.
Finde die Schrift Vera.ttf sieht allgemein auch etwas besser aus.
Auf jeden Fall steht jetzt auch im Submenü der ganze Text.
Also Walking Tall Auf eigene Faust (Walking Tall)
Thanks, und Gruss , Bert
ZitatOriginal von wino
Wollte die vollständige Update Methode benutzen, bekomme aber leider nur eine HTML-Seite als burn-0.0.009-TEN.diff. Wenn das diff auf dieser Seite gemeint ist, sollte oben 9839 und nicht 9824 stehen.
Danke für den Hinweis - ist nun geändert. Da hatte das Portal beim letzten Austausch der diff-Datei (von mir spät in der Nacht unbemerkt) die Attachment-Nummer gewechselt. wget laut Zeile 9 sollte nun wieder zuverlässig beim Abholen des diff etwaige Probleme bestimmter Browser "umschiffen".
(Sobald es überall zu laufen scheint, werde ich die Datei auch irgendwo als burn-0.0.009-TEN.tgz zur Verfügung stellen.)
Hallo TEN,
da muß ich mich doch wieder mal zu Wort melden!
ZitatDas aktuelle ProjectX hingegen hat bislang jede bereits vorab im VDR geschnittene Aufnahme (was aus Speicherplatzgründen ja ganz sinnvoll ist) anstandslos demultiplexed, d.h. es scheint schlicht nicht mehr notwendig, den eigentlichen Schnitt zwangsläufig erst bis zum burn-Durchlauf aufzuschieben, also "nach hinten" in die "SYNC"-Phase zu verlegen.
Notwendig isses vielleicht nicht mehr damit die Konvertierung durchläuft aber für ne gute Schnittqualität ist es unabdingbar (was'n Wort!), siehe dazu den Post von bitstreamout. VDR orientiert sich nur am Bild und schneidet damit möglicherweise etwas vom Ton ab und das fehlt dann beim multiplexen.
ZitatFalls ProjectX eine Cut-Liste aus VDR zuverlässig übernimmt (was jemand bestätigen und ggf. optimieren sollte, der diese Workflow-Variante mit dem Schnitt erst bei "SYNC" bevorzugt), soll das durchaus eingebaut bleiben - dann muß lediglich von no nach yes "der Schalter umgelegt werden".
Ich schneide seit einem Jahr nur noch mit ProjectX und habe keinerlei schlechte Erfahrungen damit gemacht. Ok, ich nutze meine marks2bytepos.pl um die VDR-Schnittmarken in Bytepositionen für ProjectX umzurechnen, aber damit klappt's perfekt!
Frohe Ostern
FireFly
Na denn, mal sehen, was ich in zwei Tagen so berichte.
Hier jedenfalls die entscheidene Zeile aus meiner ProjectX.ini:
Die setzt den Cut-Mode auf Zeitmarken, die offensichtlich auch der VDR benutzt. Die Anzeige in der GUI von ProjectX setzt das zwar nicht um, aber die Verwendung der Schnittmarken des VDRs und einem Kommandozeilenaufruf von ProjectX klappt bei mir bisher zuverlässig.
Insofern gäbe es sogar zwei Einsparpotentiale: Das Schneiden mit dem VDR kann man lassen (nur Schnittmarken setzten reicht) und die Pipe zwischen dvdauthor und mplex.
Das wäre zumindest meine nächste Zielmarke mit dem burn-Plugin, in zwei Tagen ... na ja, mal sehen.
Auf das auswählen der gewünschten Tonspuren kann man sicher zunächst mal verzichten, das klingt wirklich kompliziert.
ZitatOriginal von Bert
Test ist grad fertig geworden, und ich meine das Menü sieht jetzt sehr gut aus.
Finde die Schrift Vera.ttf sieht allgemein auch etwas besser aus.
Sie ist eine sehr gute Bildschirmschriftart, nur könnte sie etwas schmaler laufen (damit etwas mehr in die Zeilen passt und mehr Gelegenheit zum Textumbruch besteht).
Habe in der letzten Nacht schon im Chat nachgehakt, aber leider noch keine passenden Font-Vorschläge erhalten (bitte nur standardmäßig in den gängigen Linux-Distributionen enthaltene, oder sonstige freie, mit URLs zu Darstellung und Downloadmöglichkeit - und inkl. aller gängigen Sonderzeichen, Umlaute und Akzente!).
Es sollte auch noch eine kleine Ergänzung in den C-Code, welche den tatsächlich erforderlichen Mindestzeilenabstand anhand des Fonts ermittelt, statt fest 40px einzustellen (render.c, Zeile 227).
ZitatAuf jeden Fall steht jetzt auch im Submenü der ganze Text.
Also Walking Tall Auf eigene Faust (Walking Tall)
So hätte das wohl auch schon immer gedacht sein sollen (nur im C-Code steckten eine feste Textvorgabe und falsche Koordinaten)...:]
BTW, Dein Bild auf der letzten Seite kannst du dort auch entpackt (möglichst als PNG oder GIF) anhängen, dann lässt es sich im Portal schon in der Vorschau erkennen.
@FireFly&berndb:
Könntet Ihr (ggf. mit kls und/oder dem Team von http://forum.dvbtechnics.info) "die Köpfe zusammenstecken" und ein auf mein diff aufsetzendes diff machen, das Eure "beste" Einbeziehung der Schnittmarken bei Verwendung von ProjectX einbindet?
Ich nehme an, daß man dazu zunächst einmal in einem Mehrspur-Schnittsystem die Ergebnisse aller drei Methoden ("kls" = Schnitt im VDR - der ggf. verbessert werden muß, "FireFly" = marks2bytepos.pl, "berndb" = echo "CollectionPanel.CutMode=4" >> /etc/vdr/plugins/burn/ProjectX.ini) Frame für Frame vergleichen sollte, um den "Königsweg" zu ermitteln - was meine gegenwärtige Ausstattung (uralte "400-MHz-Mühle"!) dann doch "ein wenig" überfordert...
Hier steigt man ja kaum noch durch... Könntet ihr vll mal eine fertig gepatchte Version anbieten, so dass man sich auch als burn-Laie eine verbesserte Version holen kann??
Mfg
ZitatOriginal von balta
Hier steigt man ja kaum noch durch... Könntet ihr vll mal eine fertig gepatchte Version anbieten, so dass man sich auch als burn-Laie eine verbesserte Version holen kann??
Noch ein Momentchen Geduld bitte; ich möchte zumindest ein paar weitere Rückmeldungen (und ggf. Hosting-Angebote:ausheck) abwarten, um sicherzugehen, daß die neue Version überall funktioniert. Dann gibt's wie bereits angekündigt eine burn-0.0.009-TEN.tar.gz (mit ca. 400kB wird sie zum Anhängen an einen Beitrag hier im Forum -Limit 50kB- leider deutlich zu groß).
Eine Schritt-für-Schritt-Anleitung für ProjectX 0.90.4.00 und burn 0.0.009-TEN steht allerdings bereits hier zur Verfügung.
Zitat@FireFly&berndb:
Könntet Ihr (ggf. mit kls und/oder dem Team von http://forum.dvbtechnics.info) "die Köpfe zusammenstecken" und ein auf mein diff aufsetzendes diff machen, das Eure "beste" Einbeziehung der Schnittmarken bei Verwendung von ProjectX einbindet?
Ich nehme an, daß man dazu zunächst einmal in einem Mehrspur-Schnittsystem die Ergebnisse aller drei Methoden ("kls" = Schnitt im VDR - der ggf. verbessert werden muß, "FireFly" = marks2bytepos.pl, "berndb" = echo "CollectionPanel.CutMode=4" >> /etc/vdr/plugins/burn/ProjectX.ini) Frame für Frame vergleichen sollte, um den "Königsweg" zu ermitteln - was meine gegenwärtige Ausstattung (uralte "400-MHz-Mühle"!) dann doch "ein wenig" überfordert...
Hallo TEN,
das ist eigentlich recht einfach: kls will ich vor der 1.4 nicht "belästigen", "CollectionPanel.CutMode=4" entspricht "use Timecodes for cuts" und damit hatte ich bei mehreren Dateien damals Probleme, deshalb hatte die das marks2bytepos.pl entwickelt und schneide mit Bytepositionen. Und dmh entwickelt sowieso derzeit einen Frame-genauen Schnitt innerhalb VDR. Wenn der Schnitt innerhalb ProjectX mit Timecodes jetzt fehlerfrei funktioniert könnte man auf die marks2bytepos.pl verzichten, aber derzeit komme ich nicht zum Testen.
BTW, hats Du schon mal mit ralf1970 gesprochen wegen der Weiterentwicklung von burn-0.0.x ? Da wär's doch jetzt an der Zeit für ne 0.0.10... Und LordJaxom ist ja an der Pipe-geschichte dran von burn-0.1.x.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!