Burn: AC3+Zweikanalton+16:9 mit ProjectX

Zitat

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

Zitat

die /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

• Auf relevanten Teil zuschneiden
• Farbtiefe ohne Dithern auf 16 verringern (das ggf. bunte Hintergrundbild ist uns hierfür ja egal)
• Modus auf indizierte Palette setzen
• Speichern als interlaced Compuserve GIF

...ergibt 2 Pixel pro Byte, zusätzlich verlustfrei geschrumpft durch Lauflängenkodierung.

Zitat

Original 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

|grep --invert-match error\ in\ pes_extension

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:

• Zahlreiche Beschriftungsfunktionen wurden mit falschen Koordinaten und Größen aufgerufen, die über die vorgegebene "Fensterstruktur" des Menühintergrundes herausragten oder aber vorhandene Felder nicht richtig ausfüllten (für Interessierte: einfach burn-0.0.009-TEN.diff als Text lesen, ist entsprechend kommentiert) - keine Ahnung, wer wann diese Fehler eingebaut hat (wohl jedenfalls bevor ich überhaupt einen Brenner hatte) und warum sie so lange unentdeckt geblieben sind.
• Auf den Unterseiten scheint der Beschreibungstext um ein Zeichen zu lang (selbst bei korrekt übergebenen Dimensionen über den rechten Rand hinaus) erstellt zu werden - hiergegen wurde nun ein "Sicherheitsabschlag" in Höhe der maximal erwarteten m-Breite eingetragen (zweiter Screenshot anbei zeigt den Extremfall der nun höchstmöglichen im Wortsinne "noch im Rahmen liegenden" Zeilenlänge).
• Der verwendete Font helmetr.ttf macht wohl (zumindest mit bestimmten imlib2/freetype-Kombinationen) Probleme, durch welche trotz korrekt übergebener Strings im gerenderten Ergebnis Zeichen zu fehlen oder sich zu überlagern scheinen - das ist z.B. aus den Anführungszeichen um "Jackass" im von Bert geposteten Screenshot zu erkennen: Davon ausgehend vermute ich, daß das "Verschwinden" von Zeichen und/oder horizontalen Zeichenabständen mit unrichtigen oder von den verwendeten externen Bibliotheken inkorrekt interpretierten Unterschneidungsdaten (Kerning) zusammenhängen könnte. Ein Fontwechsel schafft Abhilfe; beiliegende Screenshots sind als Beispiel mit Schriftart Vera gerendert: cd /etc/vdr/plugins/burn; mv helmetr.ttf helmet.backup.ttf; ln -s /usr/share/fonts/ttf-bitstream-vera/Vera.ttf helmetr.ttf
  Vorschläge für eine auch am niedrig auflösenden TV-Schirm gut lesbare (freie und möglichst in den üblichen Distributionen bereits enthaltene) Schriftart sind willkommen; Randbedingungen: Geringe Laufweite (vgl. Helmet), serifenlos und "nicht zu schräg&rund", mit großen Innenräumen (vgl. Lucida) und ausreichender Dicke - bitte probeweise zunächst mit obigem Symlink-Verfahren rendern und ggf. zur weiteren Diskussion Beispielbilder posten.

Folgendes ist noch nicht ganz perfekt, d.h. nicht endgültig gelöst:

• Die Schrifthöhe muß für den jeweiligen Font automatisch ermittelt und nicht auf einen festen Wert gesetzt werden.
• Es sollte eine Möglichkeit geschaffen werden, auch ohne obige Tricks die zu verwendende Schriftart zu übergeben, d.h. nicht hardcodiert auf die problematische helmetr.ttf zu verweisen.
• Eine sinnvolle Ergänzung wäre im VDR-Menü des Plugins die Option Ziel: Nur DVD-Menüstruktur erstellen, d.h. ein ohne die Multiplexing-Operationen zeitsparend mögliches "vorverlagertes MKMENU".
• DrawText/WrapText muß jemand noch genau unter die Lupe nehmen, um zuverlässig jedes "Ausbrechen" des Beschreibungstexts in den DVD-Titel-Unterseiten zu verhindern.
• Die Genauigkeit des Fortschrittbalkens lässt sich vermutlich noch steigern.
• Die Tonspuren sind in der gegenwärtig vom kompilierten Teil des Plugins ermittelten und übergebenen Form oft unvollständig, weshalb nun sie von der aktuellen vdrburn.sh übergangen und selbst korrekt ermittelt werden. Der hierfür eigentlich zuständige C-Code sollte allerdings überarbeitet werden, um diesen "short circuit" wieder loszuwerden und auf der DVD auch die korrekte Zuordnung aller Sprachbezeichnungen (auch bei AC3 sowie Verwendung von ProjectX und Zweikanalton-Splitting) zu ermöglichen.

Zitat

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

Zitat

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?

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

Zitat

2. Im Diff-File lese ich:

Code

+# Use cut function of vdrsync (yes|no) - experimental and unnecessary with ProjectX

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

Zitat

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

Zitat

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

Zitat

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

Zitat

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