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?
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?
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.
Weil:
Zitat mencoder manpage:
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 
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...
Kleine Nebenfrage:
Warum sind keyint=1500 und me_range=64 eigentlich so hoch eingestellt?
Weil die Dateien bei meinen test dadurch etwas kleiner wurden...
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:
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?