Beiträge von FireFly

Bert: zu deinem ersten Post: solche Probleme habe ich immer wenn der Pfad "falsch" gesetzt ist. Beim Booten z.B. hat der init Prozess das /usr/local/bin nicht drin, der User aber sehr wohl so daß ein Restart unter dem User immer funktioniert, aber nach einem Boot nie. Kannst ja mal in die reccmds.conf nen Eintrag einfügen:

echo PATH   : echo PATH=$PATH

und das nach dem Booten und nach manuellem Restart prüfen. Ich habe einfach das /usr/local/bin im runvdr ergänzt.

FireFly

Wie ist denn "DVD ohne Menüs" gemeint? Sollen da mehrere Filme hintereinander abgespielt werden oder nur einer? Derzeit werden mehrere gebrannt aber nur das erste Titleset wird tatsächlich abgespielt.

FireFly

Gar nix, die sind nämlich im Posting oben auskommentiert und durch die hard-codierten Module "MODULES=..." ersetzt.
Kannst ja mal alles Schritt für Schritt bis jeweils vor einem "|" den Befehl auf der Kommandozeile eingeben und gucken was rauskommt.

@v_r: !?!
Hmmm, die Frage verstehe ich nicht. WAS die Buttons bewirken steht im dvdauthor.xml, WIE die Buttons aussehen, Position, Farbe etc. müsste dann in der menu-0.xml stehen. Letzteres ist die Eingabedatei für das spumux, das dvdauthor.xml ist die Eingabedatei für dvdauthor (Ich denke mal, daß die beiden XML-Files so heißen, hab grade keine Beispiel zur Hand. Iss aber ganz einfach: wenn am Anfang <dvdauthor ..> steht isses für dvdauthor, wenn da <subpictures> steht isses für spumux).
Übrigens mann man sich die Syntax auch mit "man dvdauthor" bzw. "man spumux" ansehen

Greets
FireFly

Ist PBC (Play Back Control) nicht nur was für SVCD? Hab' sowas im Hinterkopf...

Wieso aktiviert ihr nicht einfach die automatische Aktualisierung der channels.conf?
Einstellungen->DVB->Kanäle aktualisieren-> ....

Ich denke, da fehlt noch ein Semicolon hinter dem Ampere-Cent (geile Schreibweise, oder? :]), dann sollte die ürsprüngliche Variante auch funktionieren (is' kürzer :D)

test -e "$MPEG_PATH/px.ac3" && { cat "$MPEG_PATH/px.ac3" > "$MPEG_PATH/vdrsync.mpv" &; }

Meint jedenfalls die Bash Manpage. Bei mir hats gestern aber auch so funktioniert

FireFly

Logfiles?

Ah, jetzt, ja!

Das [demux] exit 1 gefällt mir nicht, da steht bei mir (bisher) immer exit 0. Die Prozesse von mplex und dvdauthor müßten auch noch hängen, oder? Welche Prozesse gibts denn noch auf dem System? z.B. die cat-Prozesse

dad401:

Zitat

Code

+               if [ ! -z $REQUANT_FACTOR ]; then
+                   cat "$MPEG_PATH/pjx.m2v" | /usr/local/bin/requant $REQUANT_FACTOR > "$MPEG_PATH/pjxreq.m2v"
+                   mv "$MPEG_PATH/pjxreq.m2v" "$MPEG_PATH/pjx.m2v"
+               fi    
                ...
+               test -f "$MPEG_PATH/pjx.m2v" && { cat "$MPEG_PATH/pjx.m2v" >"$MPEG_PATH/vdrsync.mpv"& }

Grmmmpfff. So hatte ich das nicht gemeint, eher so (Vorsicht, habs nicht ausprobiert)

REQUANTCMD=""
                if [ ! -z $REQUANT_FACTOR ]; then
                        REQUANTCMD="| requant $REQUANT_FACTOR "
                fi
                ...
                test -f "$MPEG_PATH/pjx.m2v" && { cat "$MPEG_PATH/pjx.m2v" $REQUANTCMD >"$MPEG_PATH/vdrsync.mpv"& }

Sonst wird ja doch wieder ne temporäre Datei gescchrieben und genau das soll ja mit der neuen Version (möglichst) vermieden werden. Dummer weise muß das Pipe-Zeichen genau auf der anderen Seite stehen als beim vdrsync.pl

Greets
FireFly

Bert: ich nutze die aktuellste Project X Version (0.90.4.00)

dad401:

Zitat

neben dem requant müssen nur noch die gewünschten Audio-IDs abgefragt werden und dementsprechend die überflüssigen PJX-Dateien gelöscht werden.

IMHO ist:
e0=Video (ProjectX.m2p),
c0=Audio1 (ProjectX.mpa),
c1=Audio2 (ProjectX[1].mpa),
bd=AC3 (ProjectX.ac3)

Alles anzeigen

Das kann so sein, muß aber nicht. Ich habe was im Hinterkopf, daß VDR mittlerweile die Sream-IDs beim remuxen selbst vergibt, so daß z.B. der Video Stream jetzt immer E0 ist - ich habe aber auch noch Aufnahmen mit E4. Und wenn jetzt im OSD ein Audio-Stream abgewählt wird - welcher ist es dann?? Und wenn's mehr als zwei mp2-Streams sind ...
Schön wäre es, wenn das burn-plugin neben den zu ignorierenden Streams in $IGNORE auch die zu übertragenden Streams in einer Umgebungsvariablen liefern würde, dann könnte man das direkt als Parameter Project X übergeben. Ebenso die Reihenfolge der Streams wäre in einer Umgebungsvariablen interessant.
In der info.vdr steht noch die Sprachen aller Audiostreams, es wäre auch schön, wenn man die direkt an dvdauthor übergeben kann (im Tag <audio lang="xx">) - da gibts noch einiges zu basteln ....

FireFly

ich habe mal n paar fehlende Übersetzungen ergänzt - Texte sind aber durchaus noch verbesserungsfähig

FireFly

Hallo zusammen,

ich habe mir das mit ProjectX nochmal etwas genauer angeguckt: Es arbeitet so, daß erst mal temporäre Ausgabedateien angelegt werden (z.B. ProjectX.$ppes$1) und die werden dann am Schluß umbenannt (z.B. in ProjectX.m2v, ließ sich mit der inode-Number rausfinden ;D) Das erklärt zumindest schon mal, warum die Fifo-Datei durch ne reguläre Datei ersetzt wird.

dad401: so ein Würgaround schwirrte mir seit Sonntag abend im Kopf rum (ist gestern abend nicht mehr ganz fertig geworden). In der vdrburn-dvd.sh habe ich den vdrsync-Aufruf folgendermaßen ersetzt:

#       vdrsync.pl -o $MPEG_PATH \
        #               -v-filter "$REQUANTCMD burn-buffers" \
        #               -a-filter "burn-buffers" \
        #               -ac3-filter "burn-buffers" \
        #               $IGNORE "$RECORDING_PATH"


                java -Djava.awt.headless=true -jar /usr/local/ProjectX/ProjectX_nogui.jar \
                        -ini /etc/vdr/plugins/burn/ProjectX.ini \
                        -demux -id 0xe0,0xc0,0xbd \
                        -out "$MPEG_PATH" -name "ProjectX" \
                        $CUTCMD \
                        $(ls $RECORDING_PATH/[0-9][0-9][0-9].vdr)


                test -f "$MPEG_PATH/ProjectX.m2v" && { cat "$MPEG_PATH/ProjectX.m2v" >"$MPEG_PATH/vdrsync.mpv"& }
                test -f "$MPEG_PATH/ProjectX.mpa" && { cat "$MPEG_PATH/ProjectX.mpa" >"$MPEG_PATH/vdrsync0.mpa"& }
                test -f "$MPEG_PATH/ProjectX.ac3" && { cat "$MPEG_PATH/ProjectX.ac3" >"$MPEG_PATH/vdrsync.ac3"& }

Damit werden die Dateien von Project X erst mal auf Platte geschrieben und dann an mplex gepiped. Nicht die ideale Lösung, aber es geht zumindest mal und man spart sich ja immer noch das schreiben vom mplex. Das $REQUANTCMD könnte man dort auch noch einbauen, dashabe ich aber nicht ausprobiert.

Gibt es eigentlich sowas wie einen "AUTHORONLY"-Mode, also wo nur das VIDEO_TS-Verzeichnsi erstellt wird ohne Brennen und ohne ISO erzeugen? Das wäre nicht nur bei Testläufen praktisch

FireFly

Das musste ja kommen
Damit werden jetzt die API-Versionen von den VDR-Versionen getrennt, so daß nicht jedesmal alle Plugins neu kompiliert werden müssen, solange sich keine API-Definition ändert.
Ville Skyttä hat dazu folgenden Lösungsvorschlag in der ML gepostet:

Zitat

Plugins that have not been changed to use APIVERSION yet upstream can be
usually locally updated with something as simple as:

Code

$ sed -i -e s/VDRVERSION/APIVERSION/g Makefile

...and somewhat off topic, the DVBDIR changes can be done with:

Code

$ sed -i -e '/^DVBDIR/d' -e 's|-I$(DVBDIR)/include||' Makefile

Das muss auf das Makefile jedes Plugins angewendet werden, dann sollte es wieder funktionieren. Mann kann aber auch die kompilierten libvdr-<name>.so.1.3.47 vom VDR 1.3.47 nehmen, denn beim VDR 1.3.48 werden die Plugins alle mit diesem Namen erstellt Habs aber noch nicht selbst ausprobiert.

FireFly

geordy: Wenn man nach dem "read" einen Zeilenumbruch einfügt steht da:

Zitat

sh: burn-buffers: command not found

Hast Du das burn-buffers vom plugin-Verzeichnis irgendwo in den Pfad kopiert (genau wie die vdrburn-dvd.sh)?

Zitat

D.h. dort die Zeile USE_CUT= entfernen oder vor den mit folgender Zeile beginnenden Code verschieben:

Ehm, ich bin mir jetzt nicht ganz sicher, ob das richtig rübergekommen ist: mit der Shell-Syntax "${USE_CUT:-no}" wird der Variablen ein Wert ("no") zugewiesen, falls die Variable noch keinen Wert hat. Wenn USE_CUT wie in diesem Fall schon irgendeinen Wert hat wird nix mehr daran geändert.

Hat schon mal jemand ProjectX mit Fifo's als Ausgabedateien benutzt?? Ich hab's eben noch mal probiert, aber nachdem ProjectX fertig ist hängt mplex immer noch, die fifo-Dateien sind weg und stattdessen sind dort normale Files mit den Namen der Fifos :§$%. Sieht so aus, als ob die Ausgabedateien gelöscht und neu anlegt werden ... Geht das überhaupt mit Java?? Sollte doch wohl, oder?

FireFly

marpiet: Ja, genau so. Das steht auch im Forum von Project X so drin.

FireFly

ein -Djava.awt.headless=true zwischen $JAVA und -jar sollte da doch helfen ab 0.90 ....
Java ist manchmal etwas kopflos

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.

Hallo TEN,
da muß ich mich doch wieder mal zu Wort melden!

Zitat

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.

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.

Zitat

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ß 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