vdr-requant.sh - verkleinern von VDR-Dateien

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

    AMD Athlon 64, Asus K8V-X mit VIA 8237 Chipsatz, 2 x Nexus-S, 1xCI
    VDR 1.6.x on Debian Lenny, latest e-tobi packages
    ----
    Intel Celeron G1610, ASRock B75 Pro3-M, 1 x TT 3200 + CI, 1 x TT 1600
    Asus GT-610, Techsolo TC-380, yaVDR 0.5

  • 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,


    Zitat

    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?


    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

  • Zitat

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

    AMD Athlon 64, Asus K8V-X mit VIA 8237 Chipsatz, 2 x Nexus-S, 1xCI
    VDR 1.6.x on Debian Lenny, latest e-tobi packages
    ----
    Intel Celeron G1610, ASRock B75 Pro3-M, 1 x TT 3200 + CI, 1 x TT 1600
    Asus GT-610, Techsolo TC-380, yaVDR 0.5

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


    Zitat

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


    Zitat

    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)

    Guter Tipp, hab ich gleich umgesetzt.


    Zitat

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


    Zitat

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

    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:



    Ich hoffe ich hab jetzt nicht irgendwo 'ne Klammer vergessen - bin bei einem Kunden und kann das Script gerade nicht testen ...


    Ralf

  • Zitat

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


    Wenn das mit pearl ging sollte das doch auch mit der shell gehen, oder?


    cu


    cP

    easyVDR 0.6: VDR: Asus M2N-VM DVI, 2GB RAM, AMD A64 X2 4000+ EE, Samsung SpinPoint T166 400GB SATA II, LG Electronics GSA-H62N schwarz DVD Brenner, TT1.5 FF, TT Budget verpackt in einem Silverstone LC17 Gehäuse.
    Client: MediaMVP


    yavdr 0.3a:Asus M4A78LT-M LE, 4GB RAM, AMD Athlon II X2 240e, Asus Geforce ENGT520, 320GB Samsung Spinpoint M7 HM320II, 300W be quiet! Pure Power L7, TT-Budget S2-1600, EKL Alpenföhn Panorama, verpackt in einem Techsolo TC-380 HTPC Gehäuse


    yavdr 0.5: Intel DH67GD, Intel Pentium G620 2x 2.60GHz So.1155, 60GB Corsair Force 3 SSD, 8GB Ram, Linux4Media S2 ver 5.4, Asus ENGT 520 Silent, CoHaus CIR


    TV: Panasonic 42" Plasma TH-42PV45

  • 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

    VDR
    ASUS A7N8X-X, AMD 2600+, 2 GB, 320 GB HD, Hauppauge DVB-S 1.3, Hauppauge Nova-S-Plus, Funktastatur
    Debian 4.0/Etch-Kernel 2.6.18-5-486
    c't-VDR 6.1 mit e-tobi 1.6.0 (neu gepatched ohne sortrecordings), acpi, vdradmin-am, burn, osdteletext, ffnetdev, audiorecorder, infosatepg, ...
    Client
    dbox2 (Sagem 2xI_C) mit Neutrino-Derivat

  • 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):

    Code
    1. 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:

    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:

    • Ein Problem gibt es mit der Umstellung von summary.vdr -> info.vdr. Da könnte man sich vielleicht nochmal drum kümmern.
    • Wenn die Filme nicht mit "%" anfangen, dann gibt es da mit dem REMOVE ein Problem. Hab gestern Spongebob-Folge Nr. 1 dadurch verloren... :§$%


    Beste Grüße DMH

    Hardware: AMD Duron 900 MHz, 256 MB Ram, 1 x 400 GB und 2 x 200 GB Maxtor, 1 x 500 GB USB 2.0, Nec DVD-RW ND-3500AG, 1 x TT 1.6 FF DVB-S, 1 x Twinhan Budget DVB-T
    Software: VDR 1.4.1, BigPatch, DMH-DVD-Archive-Patch, Kernel 2.6.12
    ---
    "Hörma, wie heißt nomma dat Instrument mit den 3 Knöppen oben drauf...? - Ja richtig, Flöte!"

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

    Hardware: AMD Duron 900 MHz, 256 MB Ram, 1 x 400 GB und 2 x 200 GB Maxtor, 1 x 500 GB USB 2.0, Nec DVD-RW ND-3500AG, 1 x TT 1.6 FF DVB-S, 1 x Twinhan Budget DVB-T
    Software: VDR 1.4.1, BigPatch, DMH-DVD-Archive-Patch, Kernel 2.6.12
    ---
    "Hörma, wie heißt nomma dat Instrument mit den 3 Knöppen oben drauf...? - Ja richtig, Flöte!"

  • 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,
    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

    --
    Antec Skeleton | Asus M3N-H/HDMI | TT DVB-C 1501 + CI | Technisat Cablestar HD2 | Hauppauge WinPVR 350 | yaVDR 0.5a

  • 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?

    VDR1:
    Gehäuse: Thermaltake Element Q
    Mainboard: Zotac IONITX-P-E
    Arbeitsspeicher: KVR1066D3N7K2/4G
    HDD: 1TB SATA
    SATA Front-Wechselrahmen
    Bluray: LG BH16NS40
    DVB: Digital Devices Cine S2 PCIe
    OS: Debian Stable
    VDR: Dev-Version mit MainMenuHooks P
    atch, div. Plugins
    Sonstiges: Kodi, XFCE


    VDR2:
    Samsung SMT-7020S mit Wakeup-Board
    HDD: 160GB 2,5" IDE
    OS: Debian Stable
    VDR:
    Dev-Version mit MainMenuHooks [size=8]Patch, div. Plugins