Verständnisfrage oder: Wieso sind meine singlepass videos besser als multipass?

    Erstmal, hallo forum :)

    Ich hab so eine kleine cam die 640x480 mjpeg filmchen aufnimmt. Alles schön und gut, nur die files sind halt riesig - ergo ich konvertiere sie in h264+aac um sie online zu stellen.

    installiert habe ich dazu mplayer-1.0_rc2_p26753-r1 und x264-0.0.20080406

    Habe mir in den letzten tagen die mencoder manpage und die dokumentation auf https://localhost/www.mplayerhq.hu durchgelesen und da steht an etlichen stellen immer wieder "Für gute ergebnisse bei wenig bitrate -> multipass. immer. ausser vllt wenn man realtime encoding macht, aber ansonsten, immer, definitiv, die entwicker empfehlen ausdrücklich multipass, usw. usf. " - ich habe jetzt etliches ausprobiert, mit den mencoder einstellungen rumgespielt - und singlepass bringt die besten ergebnisse, d.h. für meinen fall: die kleinsten dateien bei (fast) gleicher qualität wie das ausgangsmaterial.

    Aktuell bin ich bei dieser zeile für ausreichende quali bei minimaler dateigröße:

    Code
    mencoder $1 -vf hqdn3d=1:2:1 -ovc x264 -x264encopts crf=30:frameref=16:keyint=1500:bframes=16:b_adapt:b_pyramid:deblock:cabac:direct_pred=auto:weight_b:partitions=all:8x8dct:me=umh:me_range=64:subq=7:chroma_me:mixed_refs:brdo:bime:trellis=2:nofast_pskip -oac faac -faacopts quality=30 -o x264-encoded16-MAXQUALI-nopass-$1


    Das stampft z.b. diese 10 minütige 236mb mjpeg datei auf 22mb ein (258.3 kbit/s).(Vorsicht, upload der files läuft noch bis ca 24uhr)
    Jetzt kommen in dem video viel himmel und langsame bewegungen vor, deswegen ist die bitrate so gering. Bei anderen videos sinds nach dem encoding auch mal 400kbit/sek, je nachdem was da drin vorkommt.

    Wie bekomm ich das jetzt mit multipass encoding hin? ich bin ja gezwungen da direkt eine bitrate anzugeben, bevor er zu enkodieren anfängt - aber die weiss ich doch gar nicht! Gebe ich z.b. 300 an, wird die resultierende datei im beispiel oben größer als nötig, und bei actionreichen filmen wird sie kleiner als eigentlich nötig und siehts bescheiden aus. Ich müsste also etliche male enkodieren, mir das ergebnis anschauen und die bitrate anpassen bis es passt - das kann nicht sinn der sache sein.

    Die einzige verwendung für multipass encoding die ich sehe ist dass man sagt: hier, ich hab 100min video, mach mal eine 700mb datei draus mit der besten qualität die du hinbekommst. Das macht vllt sinn wenn man cds brennt aber fürs internet sind die vorraussetzungen meist anders gelegen, eher nach dem motto:
    Mach mir ein video in einer qualität die ich brauche, und mach die datei so klein wie möglich.
    Wie passt das zum multipass encoding? Garnicht, oder? Oder verpeile ich mal wieder irgendwas?

    :welcome:

    Multipass-Encodierung ist nur sinnvoll, wenn man eine bestimmte Zielgröße erreichen will, und diese Größe wichtiger ist als ein Qualitätsmaß.

    Wem im Vergleich zur Qualität egal ist, wie groß das Ergebnis wird, der soll ruhig bei 1-pass bleiben.

    Kleiner vielleicht.

    Aber hast du auch im mindesten eine Ahnung, was das bewirkt?

    Ein maximal erlaubter Schlüsselbild-Abstand von 1500 Bildern: Das bedeutet im schlimmsten Fall, dass bei einem Datenfehler (und sei es bloß eine Rundungsdifferenz beim Quantisieren) ein sich daraus ergebender Bildfehler bis zu einer Minute im Bild bleibt, bis das nächste Schlüsselbild ihn verschwinden läßt.

    Und eine Suche in einer Umgebung von maximal 64 Pixeln für die Bewegungsschätzung dauert etwa 4x so lange wie eine mit maximal 32 Pixeln, und bringt eigentlich nur etwas bei der Dokumentation eines Rennsportevents, wo sich ständig alles im Bild schnell bewegt.

    Mensch ihr macht mich ja fertig mit meinen settings - wie gesagt ich will die datei so klein wie möglich machen.
    Mit keyint=1500 fallen halt diese vorspul-frames nur alle 1500 bilder an. Ich kann trotzdem spulen, zumindest mit mplayer mit der -idx option. dann gibts aber nach dem sprung ein paar sekunden klötzchenbilder.

    LigH
    Ich hab ne ahnung was all die optionen verursachen, sofern das in der Man-page und/oder doku erwähnt wird.
    me_range=64 darum weil die dateien so am kleinsten werden. Meine videos sind halt meistens bilder vom himmel mit einigen flugzeugen die da rumflitzen, deswegen denk ich mal dass das durchaus mit dem pferderennen-beispiel vergleichen kann.

    die ganzen optionen sorgen dafür dass mein schleppi eh nur mit 0.7-1.3fps encodiert, ist aber auch egal, solang die videos gut aussehen und die dateien klein sind. den enkodiervorgang übernimmet wenn alles fertig ist eh ein skript auf einem vserver, dürfte also noch länger dauern als auf dem laptop - ist mir aber auch egal, ich lade das video dann hoch und es ist online, dann wird im hintergrund auf dem webserver rekodiert und wenns irgendwann fertig ist tauscht er die alte (große) datei gegen die neue kleine und gibt den speicherplatz frei. Das kann dann ruhig auch 2 tage später der fall sein. Das ist in etwa so der plan...

    Ich hätte eher noch mal ne andere frage - gibts noch x264encopts die das video noch kleiner machen könnten? unabhängig davon wie lang das enkodieren dauert...

    Zitat von LigH

    (und sei es bloß eine Rundungsdifferenz beim Quantisieren)

    Zitat von Mencoder-doku

    keyint=<Wert>

    Setzt das maximale Intervall zwischen IDR-Frames (Standard: 250). Höhere Werte sichern Bits und erhöhen dadurch die Qualität auf Kosten der Suchpräzision. Anders als MPEG-1/2/4 ist H.264 nicht von DCT-Versatz bei hohen keyint-Werten betroffen.

    Allerding sind so hohe "keyint"-Werte auserhalb von Animes/Toons praktisch sinnlos. Die Entwickler hatten auch schon mal angemerkt das die Algos die die Keyframes (I und IDR) setzen noch nicht 100% ausgereift sind. Das kann ich auch durch eigene Tests bestätigen.

    Also solte man lieber Konservativ bleiben:
    Keyint = fps * 10

    Zitat von bigotti5

    Kann man keyint 1500 eigentlich spulen? :D

    Beim Mplayer gibt es da machmal wirklich Probleme.

    Weil:
    Zitat mencoder manpage:

    Zitat


    esa Gründliche Suche (sehr langsam und nicht besser als umh)

    Weils nicht besser ist hab ich es gar nicht getestet. werd ich jetzt aber mal machen :)

    So, hab den obigen Film mit me=esa enkodiert. Leider war das ergebnis danach sogar geringfügig schlechter (261.4kbps, mit me=umh waren es noch 258.3kbps). Ich denke die kleine differenz sagt nicht viel aus, so dass die beiden verfahren sich je nach film nicht allzuviel tun, die manpage hatte also recht, esa ist tatsächlich nicht besser als umh. Desweiteren hat die manpage auch mit der geschwindigkeit recht - ich hatte im durchschnitt nur ca 0.17fps enkodierleistung.

    ups, ich hielt tesa für nen verschreiber, das handbuch zu mplayer schweigt sich darüber aus, habs grad ausprobiert und er enkodiert los, also lassen ich ihn mal wieder ackern, diesmal me=tesa.

    Mein Qualitätskriterium ist eigentlich eher die bildqualität. wär es größe dann hätte ich gleich crf=50 wählen können...

    Wenn ich mir die mencoder zeile so anschaue, dann denke ich dass der denoise-filter und der crf wert die einzigen optionen sind die die bildqualität beeinflussen, der rest zwingt die rechner beim enkodieren+dekodieren einfach zu mehr arbeit, dafür aber kleineren dateien. Oder nicht?

    also den scherz mit me=dia und range 4 hab ich jetzt nicht verstanden, trotzdem danke für den tip mit tesa, klappt ausgezeichnet, datei ist nur noch 19mb (237.513kbit/s) groß und sieht blendend aus!
    allerdings brauchte mein vserver für 10:30min film encodieren genau 999min und 21sek... Aber egal, hauptsache das ergebnis stimmt.

    Ich denke mehr bandbreiteneinsparung ist nicht drin, oder gibts noch irgendwas was man versuchen könnte?

    Der "Scherz" ist im Grunde ganz klar:

    Zitat

    Herr Doktor, Herr Doktor - das von Ihnen verschriebene "Placebo" hilft nicht mehr; ich brauche jetzt "Placebo forte"! ("forte" ~ "stark wirkend")

    Du schreibst, du siehst nicht wirklich eine Verbesserung. Dennoch bist du bereit, dafür unsäglich verlängerte Encodierzeiten in Kauf zu nehmen... weil du ganz fest daran glaubst, dass die auch wirklich bestmögliche Ergebnisse liefern wird? -- Dann wäre es angebracht, zum Gegencheck einfach mal die schnellste Variante zu verwenden und zu vergleichen, ob die nun wirklich schlechter aussieht, bzw. wie viel größer die überhaupt wird.

    Also mir wäre die Zeit (und der Strom) zu schade, ich würde eher ein paar KB mehr Dateigröße spendieren und statt dessen lieber eine feinere Quantisierung anstreben. Die bringt dann auch sichtbaren Erfolg. Sogar wenn nicht allzu gründlich nach Bewegungsmustern gesucht wird.

    Das Optimum ist immer ein Kompromiss unter Nebenbedingungen. So gilt beispielsweise analog die erste Weisheit der Wirtschaftslehre: "Den größten Gewinn erzielt eine Firma, wenn man sie verkauft. Unser Ziel ist statt dessen aber, den optimalen Gewinn zu erzielen und die Firma dabei trotzdem zu erhalten." Bei der Videoencodierung wäre das entsprechend: Eine zufriedenstellende Qualität erreichen, und dabei trotzdem über Nacht noch fertig werden.

    Ich glaube, die 999 Minuten (~ 17 Stunden) sind nur ein Platzhalter, weil der Programmautor nicht mehr als 3 Stellen dafür reservieren wollte.

    Zitat von FieserKiller

    ...allerdings brauchte mein vserver für 10:30min film encodieren genau 999min und 21sek... Aber egal, hauptsache das ergebnis stimmt....


    Naja jedem das seine ;D

    Vorallem wenn man berücksichtigt das das Quellmaterial nicht unbedingt 1. Güte hat was die Bildqualität angeht.

    Zitat von FieserKiller

    ...Ich denke mehr bandbreiteneinsparung ist nicht drin, oder gibts noch irgendwas was man versuchen könnte?

    Höherer CRF-Wert

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden