burn plugin - Requantisierfaktor und Warnung

    Hallo Kollegen,


    ich bin sehr begeistert von den Möglichkeiten des burn-Plugins.


    Seit ich aber von DVB-T auf DVB-C umgestellt habe, sind meine Aufzeichnungen bei gleicher Länge erheblich größer geworden, so daß ich nun viel weniger Zeit auf eine DVD bekomme.


    Außerdem ist es ärgerlich, eine Menge Rechenzeit damit zu verbraten, ein ISO zu erstellen, das sich dann als zu groß für einen Rohling herausstellt.


    Gibt es im Zuge der Weiterentwicklung die Möglichkeiten, daß burn

    • stärker komprimiert, als es das derzeit tut (wenn ich die logs richtig interpretiere, dann ist der "rescale"-Faktor derzeit auf 8 von 31 möglichen begrenzt), und
    • eine Warnung ausgibt, wenn sich herausstellt, daß das Image nicht auf die vorher eingestellte Rohlings-Größe paßt?


    Herzliche Grüße,


    herrdeh

    Zitat

    Original von herrdeh
    Seit ich aber von DVB-T auf DVB-C umgestellt habe, sind meine Aufzeichnungen bei gleicher Länge erheblich größer geworden, so daß ich nun viel weniger Zeit auf eine DVD bekomme.


    Klar, DVB-C hat die gleiche (höhere) Bitrate wie DVB-S und damit die bessere Bildqualität.


    Zitat

    Original von herrdeh
    Außerdem ist es ärgerlich, eine Menge Rechenzeit damit zu verbraten, ein ISO zu erstellen, das sich dann als zu groß für einen Rohling herausstellt.


    burn verlässt sich darauf, dasss der Requantisierer auch die angeforderte Verkleinerung durchführt.


    Zitat

    Original von herrdeh
    Gibt es im Zuge der Weiterentwicklung die Möglichkeiten, daß burn

    • stärker komprimiert, als es das derzeit tut (wenn ich die logs richtig interpretiere, dann ist der "rescale"-Faktor derzeit auf 8 von 31 möglichen begrenzt), und
    • eine Warnung ausgibt, wenn sich herausstellt, daß das Image nicht auf die vorher eingestellte Rohlings-Größe paßt?


    burn begrenzt den rescale-Faktor in keiner Weise - wie kommst Du darauf??
    Da burn zur Performancesteigerung die Zwischenschritte nicht auf Platte puffert sondern per Pipe an das nächste Programm weitergibt ist es nicht möglich vorher abzufragen, wie groß das Image wird wenn geshrinkt wird. Wie gesagt verlässt sich burn darauf, dass der angeforderte Shrinkfaktor auch umgesetzt wird.


    Gruß
    FireFly

    Servus,


    Dank für die Antwort.
    o.k., ich habe also verstanden, daß nicht burn selbst, sondern der Requantisierer bestimmt, wie heftig komprimiert wird.


    Was ich ganz am Anfang in einem burn-log gefunden habe:


    Zitat

    [render] INFO: [mpeg2enc] Quality factor: 8 (Quantisation = 9) (1=best, 31=worst)


    Da scheint doch eine Begrenzung drin zu sein - mit einem "Quality factor" von 31 kriege ich wahrscheinlich ein grottige Qualität - aber halt auch viel mehr auf eine DVD. Kann ich das irgendwo vorgeben? Hat mpeg2enc eine config-Datei?


    Herzliche Grüße,


    herrdeh

    Öha - das hat also mit der Requantisierung der Filme nix zu tun.


    Trotzdem bleibt für mich die Frage offen:
    Mit ffmpeg kann ich einen DVB-C-Mitschnitt locker im Verhältnis 1 : 7 runterkomprimieren, und die Qualität des Resultats ist durchaus o.k.


    Mit dem VDR-Requantisierer erreiche ich maximal 1 : 1;5 - da sollte doch noch Luft drin sein??? -


    Herzliche Grüße,


    herrdeh

    Zitat

    Original von herrdeh
    Mit dem VDR-Requantisierer erreiche ich maximal 1 : 1;5 - da sollte doch noch Luft drin sein???


    DEN VDR-Requantisierer gibts nicht. burn bietet drei zur Auswahl an (M2VRequantizer von Metakine, tcrequant von transcode und requant von lxdvdrip), wobei Deine Distri aber evtl. welche ausschließt/nicht anbietet.
    Du kannst auch probieren, ob Du in der vdrburn-dvd.sh einen Eintrag so umbauen kannst, dass er ffmpeg benutzt (dann hätte ich aber gerne die Änderung für die nächste Release ;D)

    Hallo,


    das wär' klasse, wenn sich da mal jemand drum kümmern würde. In meinem (easy)VDR arbeitet wohl projectX als Requantisierer - kann man dem nicht einfach irgendwie klarmachen, es soll gegebenenfalls heftiger komprimieren und dabei eine schlechtere Qualität akzeptieren?


    Habe gestern 5 Folgen á ca. 2,8GB mittels Toast auf ein ca. 3,6GB großes DVD-Image gebracht. Fast 20h Rechenzeit - soviel zur Effizienz professioneller Programme… - Aber die Qualität ist durchaus o.k. Die Orginale waren Analog-Filme aus den 1970ern - da ist die Schärfe eh' nicht sooo doll…


    Es tät' mich sehr freuen, wenn wir da vorwärts kämen - für den, der mir als erster sagen kann, wie ich im Rahmen des burn-Plugins ein Kompressionsverhältnis von 1 : 5 bei ordentlicher Qualität hinbekomme, setze ich 6 Orginal Nürnberger Lebkuchen als Preis aus - echte Bäcker-Qualität, nicht den Fabrik-Plempel, den man außerhalb der fränkischen Lande für Lebkuchen hält.


    Herzliche Grüße,


    herrdeh

    1:5 geht nur mit re-sizen und re-encoding - das ist nicht mit a weng Koung getan :P


    Es gibt kein re-encoding in Burn, das was du da gesehen hast ist vom erstellen des menüs das macht den bock nicht fett. Was du möchtest ist yacoto, vdrrip oder ähnliches

    VDR User: 87 - LaScala LC14B - LG/Phillipps 6,4" VGA Display | Asrock H61/U3S3 | G630T | 1x 16GB Mobi Mtron 3035 1x WD 750GB 2,5" |1x L4m DVB-S2 Version 5.4

    vdr-wiki YaVDR |YaVDR Blog

    Hallo,


    habe mal ein bißchen mit ffmpeg rumgespielt:


    Wenn ich mit


    Code
    ffmpeg -i 001.vdr -target pal-dvd -acodec copy -qscale 15 001.mpeg


    eine VDR-Aufnahme umwandle und sie danach in *.vdr umbenenne, läßt sich daraus problemlos eine DVD machen.


    Etwas problematischer ist die 002.vdr - da passiert es manchmal, daß kein Ton mehr zu hören ist, gelegentlich wurde die auch überhaupt nicht umgewandelt. Ich interpretiere (laienhaft) die Fehlermeldungen so, daß bei 002 und späteren keine Header-Infos da sind, die ffmpeg auslesen könnte und dann auf reines Raten angewiesen ist. Aber man sollte ja die Parameter aus der 001 an den Komprimierungsvorgang für 002, 003 ff. übergeben können.


    -qscale 15 ist natürlich sehr brutal, man sieht dann sehr deutliche Klötzchen - aber dafür geht es auch ca. 1:10 runter…


    Tonsynchronisationsprobleme hatte ich keine - kenne ich aber von ffmpeg ohnehin nicht…


    Die Berechnung der Zieldatengröße scheint schwierig zu sein - im Anhang ist eine Graphik, wie qscale wirkt - man scheint das nicht richtig rechnen zu können… - Aber auch "Profi"Software hat da Probleme - "Toast" hat bei mir ein paar Filme von 7,3GB auf 3,6GB geschrumpft für eine 4,7er-DVD - das finde ich nun nicht ganz optimal…


    Also ich denke, ffmpeg wäre weitergehender Versuche wert.


    Herzliche Grüße,


    herrdeh

    Hey suppppr,


    ich stelle mich natürlich gern selbstlos als alpha-, beta- und gamma-Tester zur Verfügung.


    Noch so einen Idee: Die Frage der requantifizierungsfaktoren scheint ja nicht so ganz trivial zu sein - und der qscale-Faktor ist womöglich noch schwieriger in den Griff zu kriegen. Ich vermute außerdem, daß die Komprimierungserfolge vom Ausgangsmaterial abhängen.


    Könnte man nicht auf dem VDR eine Tabelle führen, in der Komprimierungs-Resultate und zugehörige qscale-Faktoren dauerhaft gespeichert werden. Für jedes neue Projekt könnte das Skript dann raussuchen, welcher qscale-Faktor für diese DVD am besten paßt - und im Laufe der Zeit auch noch quasi "dazulernen".


    Herzliche Grüße,


    herrdeh

    Zitat

    Original von Copperhead
    Was erwartet denn burn, am ende von [demux] und [requant]. Ich möchte als Hack den ganzen Teil überspringen und erst bei [mplex] wieder einsteigen.


    ?!?
    Ich dachte, ich wäre derjenige, der die Skripte nicht verstanden hätte ....
    demuxpx erzeugt Dateien namens vdrsync.*
    requant und mplex lesen von einem (bzw. mehreren) Fifo-File(s) und schreiben jeweils in ein Fifo-File
    Die Fifo-Files werden von Plugin selbst angegelegt und die Namen in Umgebungsvariablen dem Skript übergeben.
    Und Nein, ich werde daran nichts ändern, ich komme so schon nicht nach

    So hier mal meine bisherigen ergebnisse.


    Ziel meinerseits war es. ProjectX requant und mplex zu ersetzten -> durch einen ffmpeg aufruf.


    Soweit klappt das auch, im Anhang ist ein Skript, indem man eine *.ts Aufnahme, einen Requant-Faktor und und ein Ausgabeverzeichnis angibt.


    Die Aufnahme wird dann in eine test.mpg ins Ausgabeverzeichnis gelegt.



    Nun zu den Sachen die nicht funktionieren.


    Es kommt kein AC3 durch... Ich habe schon so einiges probiert aber letztenendes nimmt er entweder nur AC3 oder nur MP2. Bei mehreren Streams beschwert er sich "Number of stream maps must match number of output streams"



    Vielleicht findet jemand anderes eine Lösung und dann kann ich weiter machen.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden