Hi,
Ok, ich hab jetzt vdr-requant-list.sh in mein vdrconvert Queuemanagement integriert. Was ich aber noch nicht herausgefunden hab, wie kann ich jetzt vdr-requant den Faktor über die Commandline mit auf den weg geben?
bye
Marcus.
Hi,
Ok, ich hab jetzt vdr-requant-list.sh in mein vdrconvert Queuemanagement integriert. Was ich aber noch nicht herausgefunden hab, wie kann ich jetzt vdr-requant den Faktor über die Commandline mit auf den weg geben?
bye
Marcus.
Hallo gonz,
wenn sich bei vdrsync.pl so oft etwas geändert hat, sollten wir da wirklich von weg. Ich habe deinen Code mit tcprobe ausprobiert, funktioniert bei mir. Kannst es meinetwegen gerne so einbauen.
Noch etwas, ist mir eben aufgefallen: Bei mir werden requantisierte Aufnahmen immer etwas kürzer als die Originale, aus einer Stunde werden etwa 59 Minuten. Ich kann aber nicht feststellen, dass irgendwo etwas fehlt. Verliert Requant evtl. mal hin und wieder einen Frame oder wie ist das zu erklären?
Gruß,
mhunstig
Hi mindless,
ZitatOk, ich hab jetzt vdr-requant-list.sh in mein vdrconvert Queuemanagement integriert. Was ich aber noch nicht herausgefunden hab, wie kann ich jetzt vdr-requant den Faktor über die Commandline mit auf den weg geben?
es wird in vdr-requant-list.sh fuer jede Aufnahme "vdr-requant.sh after pfad/zu/video"
ausgefuehrt. Bei dem Parameter after wird von vdr-requant.sh der DEFAULT_FACTOR
verwendet (normal 1.3), den Du im Script selbst aendern kannst.
cu
gonz
ZitatOriginal von gonz
es wird in vdr-requant-list.sh fuer jede Aufnahme "vdr-requant.sh after pfad/zu/video"
ausgefuehrt. Bei dem Parameter after wird von vdr-requant.sh der DEFAULT_FACTOR
verwendet (normal 1.3), den Du im Script selbst aendern kannst.
Ja, das hab ich befürchtet Das ist ein Punkt, der mir an vdrconvert überhaupt nicht gefällt, daß ich keine Möglichkeit hab aus dem OSD ein Skript mit unterschiedlichen Parametern aufzurufen - aber naja, damit muß ich wohl leben
bye
Marcus.
Hi,
hier also die neue Version, die nun tcprobe zum Feststellen der Bitrate verwendet
mhunstig: Bzgl. der kuerzer gewordenen Aufnahmen kann ich nur vermuten dass
genindex da etwas "nicht ganz korrekt" macht. Den Effekt hab ich auch schon bemerkt,
fehlende Frames oder zu schnelles Abspielen konnte ich jedoch nicht feststellen...
(Thomas und LordJaxom haben mir glaubhaft versichert dass die index.vdr zurate
gezogen wird bei der Laufzeitberechnung durch VDR).
cu
gonz
Hallo,
da bin ich wieder und gleich wieder mit Problemen:
Wie sich hier herausgestellt hat, waren die bisherigen Versionen der Requantisierungsfaktorberechnung fehlerhaft, da sie nicht die tatsächliche Bitrate als Ausgangspunkt verwendeten, sondern die von den Sendern angegebene, die teilweise um mehr als den Faktor 2 abweicht.
Ich habe nun vor, die Ausgangsbitrate aus der Größe der .vdr-Dateien und der Länge der Aufnahmen zu bestimmen.
Leider scheitert mal wieder vieles daran, dass ich nicht gut genug in Shellskripten bin.
Die Gesamtgröße der Datei bekomme ich mit:
du -c ???.vdr | grep -v vdr | awk -F' ' '{print $1}'
Ich habe keine Ahnung, wie ich an die Länge der Aufnahmen komme. Wie es in C geht, steht wohl hier, aber mit C kenne ich mich garnicht aus, außerdem soll es ja möglichst ein Shellskript bleiben. Gibt es irgendein Kommandozeilenprogramm, dass die Länge einer Aufnahme aus der index.vdr holt? Da müsste sie doch eigentlich drinstehen.
Die Audiobitraten müsste ich ja eigentlich von der errechneten Gesamtbitrate abziehen. Mit
vdrsync.pl -audio-only -i 001.vdr | grep Bitrate | awk -F' ' '{print $2}'
bekomme ich eine Liste. Ich hoffe, dass das mit anderen vdrsync.pl-Versionen auch klappt. Da müsste dann die erste Hälfte der Zahlen aufaddiert werden. Tja, meine Programmierkenntnisse... Wenn ich es nicht hinbekomme, ziehe ich einfach einen festen Wert ab, sollte reichen, da vdr-requant den mitgegebenen Faktor sowieso nicht ganz exakt umsetzt.
Ihr seht, ich brauche Hilfe, sonst bekomme ich das nicht hin. Danke schonmal im Voraus.
Matthias
Tipp:
du -s (anstatt du -c) bringt dir gleich die eine Zeile, die du dir mit "grep vdr" am Ende aufwendig baust.
Wenn du noch einen gestarteten Prozess sparen willst, und nebenbei die gesuchte Dateigröße auch gleich auf einer Variablen haben möchstest, empfehle ich folgende Zeile:
read SIZE NAME < <(du -s ???.vdr)
Danach steht auf $SIZE die Größe und auf $NAME noch mal der Name der Datei ($NAME kannst du ja ignorieren - angegeben werden muß die zweite Variable ansonsten landet die ganze Zeile die "du" liefert auf der ersten Variablen und das ist ja nicht so richtig das was wir erreichen wollten).
Entsprechend bekommt man mit
read DUMMY BIT_RATE < <(vdrsync.pl -audio-only -i ???.vdr | grep Bitrate)
die gesuchte Bitrate auf $BIT_RATE.
Zum eigentlichen Thema: wenn ich es richtig verstanden habe steht in index.vdr für jeden Frame ein Record der die Nummer des eigentlichen .vdr Files, die Art des Frames und den Offset an dem der Frame im File zu finden ist enthält. D.h. die Länge des Files ist direkt proportional zu Länge des Films. Die Recordgröße ist 8 Byte (ein int, 2 char, ein short als Filler).
Bei 25 Herz pro deinterlastem Frame biete ich folgende Berechnung:
read IDX_SIZE DUMMY < <(du -b index.vdr)
SECONDS_OF_MOVIE=$(( $IDX_SIZE / ( 25 * 8 ) ))
Das bringt zumindest bei mir sinnige Werte. Vielleicht kannst du ja damit was anfangen.
Ralf
Hallo Ralf,
Danke für die Hilfe.
Zitatdu -s (anstatt du -c) bringt dir gleich die eine Zeile, die du dir mit "grep vdr" am Ende aufwendig baust.
Das hatte ich von dem Parameter -s auch erwartet. Leider tut er das nicht, sondern gibt mir genau die Zeilen von du -c zurück, die ich _nicht_ haben will.
ZitatWenn du noch einen gestarteten Prozess sparen willst, und nebenbei die gesuchte Dateigröße auch gleich auf einer Variablen haben möchstest, empfehle ich folgende Zeile:
read SIZE NAME < <(du -s ???.vdr)
Guter Tipp, hab ich gleich umgesetzt.
ZitatEntsprechend bekommt man mit
read DUMMY BIT_RATE < <(vdrsync.pl -audio-only -i ???.vdr | grep Bitrate)
die gesuchte Bitrate auf $BIT_RATE.
Das Funktioniert, wenn ich nur eine Audiospur habe. Aber was, wenn ich mehrere habe, z.B. eine Stereo und eine AC3? Dann muss ich Zahlen, die in zwei oder mehreren Zeilen stehen, addieren. Und dafür habe ich leider noch keinen Bash-Befehl gefunden.
ZitatZum eigentlichen Thema: wenn ich es richtig verstanden habe steht in index.vdr für jeden Frame ein Record der die Nummer des eigentlichen .vdr Files, die Art des Frames und den Offset an dem der Frame im File zu finden ist enthält. D.h. die Länge des Files ist direkt proportional zu Länge des Films. Die Recordgröße ist 8 Byte (ein int, 2 char, ein short als Filler).
Scheint zu stimmen. Ich habe es an drei Aufnahmen ausprobiert und es hat 36,32,39 Sekunden mehr ausgegeben, als der VDR anzeigt. Wahrscheinlich steht noch irgendwas anderes in der index.vdr. Ich ziehe jetzt einfach immer 35 Sekunden ab, das reicht an Genauigkeit locker.
Bleibt nur noch das Problem mit der Audiobitrate, dann kann ich mal ein paar Testläufe mit vdr-requant starten.
Gruß,
Matthias
Mehrere Audiospuren gehen natürlich auch:
IDX=1
CUMULATED_BIT_RATE=0
while read DUMMY BIT_RATE; do
BIT_RATES[$IDX]="$BIT_RATE"
CUMULATED_BIT_RATE=$(( ${BIT_RATES[$IDX]} + $CUMULATED_BIT_RATE ))
IDX=$(( $IDX + 1 ))
done < <(vdrsync.pl -audio-only -i ???.vdr | grep Bitrate)
for i in ${BIT_RATES[@]}; do
echo $i;
done
echo "=$CUMULATED_BIT_RATE"
Alles anzeigen
Ich hoffe ich hab jetzt nicht irgendwo 'ne Klammer vergessen - bin bei einem Kunden und kann das Script gerade nicht testen ...
Ralf
ZitatOriginal von mhunstig
Ich habe keine Ahnung, wie ich an die Länge der Aufnahmen komme. Wie es in C geht, steht wohl hier, aber mit C kenne ich mich garnicht aus, außerdem soll es ja möglichst ein Shellskript bleiben. Gibt es irgendein Kommandozeilenprogramm, dass die Länge einer Aufnahme aus der index.vdr holt? Da müsste sie doch eigentlich drinstehen.
Das gleiche Problem hatten xpix und hulk mit xxv auch.
xxv-Release
Zuerstwurde "vdrsync -i" benutzt, was aber wohl sehr Ressourcenhungrig ist.
Dann wurde "du" benutzt und durch die bitrate geteilt -> Nachteil: sehr ungenauer Wert, auch wenn eine CBR benutzt wird
Hulk hat es dann mittels index.vdr geschafft (siehe letzter Post im obigen Link):
ZitatAlles anzeigenOriginal von Hulk
Ich bin gerade auf den Gedanken gekommen, das man doch nur index.vdr verwendet werden muss...
Den die Datei speichert die Byte Positionen aller Frames ab.
lt. VDR Quellcode
Anzahl der Frames = Dateigröße von index.vdr / sizeof(struct tIndex) - 1
also => Anzahl der Frames = Dateigröße von index.vdr / 8
Filmlänge [s] = Frames / FRAMESPERSEC (25)
Damit passen die Zeiten :
(pearl)
Wenn das mit pearl ging sollte das doch auch mit der shell gehen, oder?
cu
cP
Hallo Matthias,
wenn ich die bisherige Diskussion richtig verstehe, dannn möchtest Du alles mit einem Shell-Skript erledigen und micht mit perl. Persönlich würde ich zu perl raten, auf Grund der Mächtigkeit der Möglichkeiten, aber es geht auch irgendwie mit der bash.
1. Größe des Films
du -c ???.vdr liefert zeilenweise die Größe der Dateien und in einer abschließenden Zeile die Summe der Größen. Was fehlt ist ein -L (also: du -cL ???.vdr), damit werden Links verfolgt, was bei einer Verteilung auf mehrere video-Verzeichisse passieren kann. Wenn Du die Größe in Bytes brauchst, kommt noch ein -b dazu. Um nur die letzte Zahl zu lesen, geht beispielsweise:
while read S NAME ; do SIZE=$S ; done < <(du -cbL ???.vdr)
Dann steht in $SIZE die Summe der Größen.
2. Länge des Films
Ich kenne die Definition von index.vdr nicht, wenn tatsächlich jeder Frame und nicht nur I-Frames drin steht, dann ergibt sich die Länges des Films durch (Länge von index.vdr in Bytes) / 8 Bytes / 25 und damit gelten die Zeilen von Ralf:
read IDX_SIZE DUMMY < <(du -b index.vdr)
SECONDS_OF_MOVIE=$(( $IDX_SIZE / ( 25 * 8 ) ))
Gruß,
Armin
Hallo,
Die neue Version ist einsatzfähig. Danke für die vielen Tipps, besonders an Ralf, ohne den das ganze nicht laufen würde.
In der vdr-requant.sh gibt es eine Zeile (114 in gonz' letzter Version):
BRINPUT=$( vdrsync.pl -script-output -i $2/001.vdr | grep Bitrate | head -n 1 | awk -F: '{print $2 }' | sed -n '$ p' )
Die muss ersetzt werden durch:
read FILESIZE DUMMY < <(du -c $2/???.vdr | grep -v vdr)
#read INDEXSIZE DUMMY < <(du -b $2/index.vdr) # Schöner, aber führt auf meinem System zu einem Fehler
INDEXSIZE=$(du -b $2/index.vdr | awk -F' ' '{print $1}') # Bewirkt das gleiche wie vorhergegangene Zeile.
SECONDS=$(($INDEXSIZE / ( 25 * 8 ) -35))
# Code von Ralf1970 - Danke
IDX=1
BRAUDIOx2=0
while read DUMMY BIT_RATE; do
BIT_RATES[$IDX]="$BIT_RATE"
BRAUDIOx2=$(( ${BIT_RATES[$IDX]} + $BRAUDIOx2 ))
IDX=$(( $IDX + 1 ))
done < <(vdrsync.pl -audio-only -i $2/???.vdr | grep Bitrate)
BRAUDIO=$(($BRAUDIOx2/2))
BRINPUT=$(echo "scale=0; $FILESIZE/$SECONDS*8-$BRAUDIO/2000" | bc )
Alles anzeigen
Ich hatte keine Zeit, es ausgiebig zu testen, sondern hab nur zwei South Park-Folgen mit unterschiedlicher Bitrate auf 3000kbps bringen lassen. Die Dateien sind hinterher ungefähr gleich groß, scheint also geklappt zu haben. Die Qualität ist auch OK, aber bei dem Fall, in dem der Faktro größer war (etwa 1.6) sind bei Szenenwechseln teilweise äuffällige bunte Artefakte zu sehen.
Viel Spaß beim Testen. Schreibt doch mal, was für Bitraten ihr so nutzt.
Matthias
Wollte mal ausprobieren, was das vdr-requant so leistet. Also installiert und versucht. (Mit meinen Spongebob-Folgen) Allerdings sind bei den Faktoren 1.5, 1.4 und 1.3 (in der Reihenfolge) bei Bildwechseln ziemlich störende, über den ganzen Bildschirm verteilte, bunte Klötzchen zu sehen. Das war für mich nicht tragbar. Mit welchen Faktoren arbeitet Ihr denn?
Dann hab ich gedacht, dass das an dem Zeichentrick liegt. Aber auch bei Realfilmen war die Quali nicht überzeugend und bei Schnitten (nicht vdr-Schnittmarken, sondern Bildwechsel im Film selbst) kamen häufig die bunten Klötzchen!
tüddelkopp:
Mit welchem Faktor hast Du die Simpsons-Folgen recodiert? Der Unterschied zu dem Original ist zwar sichtbar, dennoch traten keine bunten Bilder bei Schnitten auf.
Probleme:
Beste Grüße DMH
Die Simpsons requantisiere ich immer mit Faktor 1.4 - 1.5
Dann werd ich das mit meinen Simpsons-Folgen auch mal versuchen... Ist es ein Unterschied, ob man requant oder tcrequant benutzt? Hatte meine Versuche mit tcrequant ausgeführt...
Ich habe auch immer tcrequant benutzt und kann daher zu unterschieden nichts sagen.
Hallo,
ich finde dieses teil wirklich klasse, jedoch wie sieht das mit der unterstützung von großen Dateien aus? 192 minuten 3sat und größe etwa 8-9GB
was muss ich da einstellen damit ich es konvertieren kann?
das sind die dateigrößen nach abbruch mit fehler im ersten lauf
drwxr-xr-x 2 root root 4096 Jan 27 01:37 .
drwxrwxr-x 4 root users 4096 Jan 27 01:36 ..
-rw-r--r-- 1 root root 228298752 Jan 27 02:08 vdrsync0.mpa
-rw-r--r-- 1 root root 114126848 Jan 27 02:08 vdrsync1.mpa
-rw-r--r-- 1 root root 4942012416 Jan 27 02:08 vdrsync.mpv
ich vermute es liegt irgendwo an einer 4gb max. dateigröße es ist ein ext3 fehler? danke ich nicht eher vdrsync macht da nicht mit
hier noch die abbruchfehlermeldung
part 1/4 - vdrsync.pl
DEBUG: starting: vdrsync.pl
ERROR: vdrsync.pl exited with error.
EDIT: Ich vermute das Problem hat sich wohl erledigt, da die Aufnahme wohl dermassen defekt ist und sich mit vdrsync nicht bearbeiten lässt.
hi georg3003,
in der tat ist hier vdrsync.pl das problem, bzw. die defekte aufnahme. vdr-requant.sh sollte grosse aufnahmen automatisch korrekt handhaben.
cu
gonz
Hi,
ich glaube nicht das vdrsync das Problem ist, bei mir wird durch die Benutzung von vdr-requant.sh aus einem
[tcprobe] MPEG packetized elementary stream (PES)
mit dem vdrsync.pl umgehen kann, ein
[tcprobe] MPEG program stream (PS)
den vdrsync.pl dann nicht mehr versteht.
Gibt es dafür einen Lösungsansatz?
ratata
Wäre es nicht besser, auf eine neuere vdrsync-Version zu wechseln?
Die 0.1.1.2 steigt oft mit Fehlern aus.
Die 0.1.1.3 funktioniert bei mir besser.
Allerdings haben die Outputs damit andere Namen.
Oder hab ich was verpasst?
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!