Danke, Firefox war da kulanter und hat nur das Englisch größer geschrieben.
XviD Lumimasking
-
-
Zitat von Kopernikus
Falls es jemanden interessiert:
http://xvid.ist-dein-freund.de
hier befindet sich ein Patch mit einem neuen Plugin, das nicht mehr diese komplizierten Profile verwendet.
Viel Spass beim Testen!
Hi,
so ganz schnalle ich es noch nicht. Wie lautet denn nun eigentlich ein Befehl? Ich verstehe es so, dass ich eine Formel hinterlegen muss?
Kann mir mal jemand eine beispielhafte commandline dazu schreiben? - vielen Dank -
Du kannst bei encraw zusätzlich den parameter -hvs_aq oder -hvs_lmb angeben. Dahinter kommt ein String mit der Formel.
Also z.B.
./xvid_encraw -i c:/video/ .... -hvs_aq "70 lc_lum - theta quant 1 - x lc_lum 70 - theta quant x quant +"
wobei das in "" der Formel
"theta(70 -lc_lum)*(quant - 1) + theta(lc_lum - 70)*quant" in normaler Schreibweise entspricht.
In anderen Worten ist dies
wenn lc_lum < 70
dann erniedrige quant des Blocks um eins
sonst nichtAlso dunkle Blöcke sollen niedriger Quantisiert werden.
Man könnte diese Formel dann aber auch noch tunen, so dass in insgesamt sehr dunklen Frames das wieder anders gehandhabt wird, oder dass bei sehr hohen Quantizern nochmals anders reagiert wird.
Das Problem ist halt, sich eine Formel zusammenzubasteln, die das tut, was sie soll. Diese Formel beinhaltet die ganze Magie des Lumimaskings. Die des "traditionellen Lumimaskings" habe ich ja auf der Seite zitiert. Die ist so länglich, weil der Algo sehr viele ifs enthält, die man halt als summen aus Theta Funktionen schreiben muss.
Bei den Lambdas funktioniert das eigentlich genau gleich, ein lambda für jeden Block, große Lambdas sind bessere Qualität und niedrigere Bitrate und andersrum.
-
Kleine Detailfrage:
Zitat"70 lc_lum - theta quant 1 - x lc_lum 70 - theta quant x quant +"
Äh, muss hier also im UPN-String der Buchstabe "x" für das Multiplikationszeichen "*" geschrieben werden?(Auf jeden Fall muss ich aufpassen, nicht das "?" für if-then-else Sachen zu benutzen ... Macht der Gewohnheit, von wg. MaskTools ...)
-
Ja, das mit dem x ist ein Relikt. Beim Testen hatte ich ein Kommandozeilentool, und da wurde * immer durch verrückte Dinge ersetzt, die den Parser durcheinanderbrachten.
-
Unter Linux wird eine Windcard auch vom Betriebssystem bereits durch eine Dateiliste ersetzt, bevor die Kommandozeile das Programm erreicht. Wer unter Linux Sternchen übergeben will, der muss sie "gewaltsam" ausquoten!
Leider gibt es drei Varianten von Quotes, und ich weiß nie, welche davon die geeignete ist. "Double quotes" sind wohl harmlos (nur gegen Leerzeichen und Minus am Anfang), `Back quotes` müssten eigentlich die sichersten sein, ´Forward quotes´ hatten auch noch eine Sonderbedeutung.
-
Back Quotes um einen Befehl ersetzen bei der bash den gequoteten Ausdruck mit der Ausgabe des Befehls.
-
@ Kopernikus
Vielen Dank für Deine ausführliche Erklärung.
Leider sieht es aber so aus, dass ich das wohl nicht hinbekommen werde - ich kapiere einfach zu wenig von den Formeln und weis noch immer nicht was ich machen soll. So wie ich es verstanden habe, ist die oben aufgeführte Formel unvollständig da nur als Beispiel aufgeführt. Eine vollständige Formel mit dem klassischen lumimasking gibt es auf der verlinkten Seite. Aber wie nun das in Praxis als richtige commandline aussieht bleibt weiter geheimnisvoll für DummUser wie mich
Aber ich bin gespannt auf Eure Tests und finde das Projekt richtig spannend - weiter so
-
Zitat von JoeB
@ Kopernikus
Vielen Dank für Deine ausführliche Erklärung.
Leider sieht es aber so aus, dass ich das wohl nicht hinbekommen werde - ich kapiere einfach zu wenig von den Formeln und weis noch immer nicht was ich machen soll. So wie ich es verstanden habe, ist die oben aufgeführte Formel unvollständig da nur als Beispiel aufgeführt. Eine vollständige Formel mit dem klassischen lumimasking gibt es auf der verlinkten Seite. Aber wie nun das in Praxis als richtige commandline aussieht bleibt weiter geheimnisvoll für DummUser wie mich
Aber ich bin gespannt auf Eure Tests und finde das Projekt richtig spannend - weiter so
Ein Aufruf in der Praxis sieht aus wie bisher, nur dass dieser eine (oder beide) Parameter dazukommen.
Also z.B. was ich zum testen verwendet habe:
./encraw -i ~/videos/test/katze.yuv -type 0 -single -hvs_aq "quant 2 +" -o ~/videos/test/katzeout.m4v
Der Aufruf sorgt dafür, dass für jeden Block der Block Quantizer nach folgender Formel ausgerechnet wird:
block_quant = quant + 2
D.h. jeder Block in I und P Frames hat quantizer 6 (ich glaube 4 ist standard), in Bframes 9.
Es gibt da ein Problem mit der Ausgabe von enc_raw, es werden die von der Rate Control gewählten Quantizer ausgegeben, anstatt die wirklich im Bitstream geschriebenen.
Aber das ist ja jetzt noch nichts revolutionär neues, da hätten wir ja auch einfach eine Zone mit Quantizer auf 6 erstellen können.
Spannend wirds, wenn wir die Quantisierung von den Bildeigenschaften abhängig machen. Das machte das bisherige Lumimasking ja auch, dunklen Bereiche wurden stärker quantisiert und helle auch.
Wenn uns das nicht gefällt, weil z.B. dunkle Bereiche sehr absaufen und blocken, können wir uns z.B. überlegen, dass wir dunkle Bereiche weniger stark quantisieren wollen. Eine Möglichkeit wäre z.B. die vorher genannte Formel (die so auch funktionieren sollte).
Jetzt könnten wir uns auch überlegen, dass wir das noch stärker tun wollen, wenn der Frame insgesamt sehr hell ist. Dann müssen wir die Formel halt entsprechend modifizieren, so dass sie bei hohen Werten für gl_lum und bei kleinen Werten für lc_lum kleinere Werte produziert.
Man könnte z.B. versuchen:
"lc_lum 5 + gl_lum 5 + / quant x"
das entspricht (lc_lum + 5)/(gl_lum + 5) * quant
Das würde zumindest qualitativ ungefähr das machen, was wir uns überlegt haben. Meistens wird lc_lum ungefähr gleich gl_lum sein, dann ist der Blockquantizer ungefähr quant (also dem von der RC zugeordneten Quantizer). Wenn lc_lum deutlich kleiner ist als gl_lum, dann hätten wir niedrigere Blockquantizer. aber flass lc_lum größer ist, wäre der Blockquantizer größer als quant. Das wollen wir aber nicht, man müsste das irgendwie korrigieren, z.B. indem man dieses Verhalten durch multiplikation mit geeigneten Thetafunktionen einschränkt.
Ich hoffe, das hilft irgendwie. Das große Problem ist das Zusammenbasteln der Formeln, so dass sie tut, was man macht.
-
Es gibt eine neue Version mit ein paar Updates:
Für Multiplikation funktioniert jetzt auch *
min,max und ? hinzugefügt (extra für Didée)
pi und e als literale
paar kleine Optimierungen -
Kennt einer von euch ein relativ kurzes (1000-2000 Frames), frei verfügbares Sample, bei dem Xvid (bei konstanten niedrigen Quantizern) an seine Grenzen stößt?
-
Das frei verfügbar ist ein Problem -> würde eventuell nen Trailer von Batman oder so als Ausgangsmaterial empfehlen. Ansonsten haben Gleitz&Co für ihren Mpeg2 Encodervergleich doch damals von irgendwem so nen Achterbahn Clip gehabt, war der frei?
Wenn ein kürzerer Clip reichen würde, würde ich einen der Sony Bravia Clips empfehlen. Vielleicht auch interessant: http://www.highdefforum.com/showthread.php?t=6537
Da wird auch auf das Wöchentliche StudiMagazin der FH Karlsruhe (http://fbmn-hit-www.fh-karlsruhe.de/extrahertz/07-…dungen-2006.htm) gelinkt,...Cu Selur
-
m.E. auch seeehr gut zum Testen: dunkle Nachtszene, Leute sitzen um ein Lagerfeuer oder so, und werden nur von dem flackernden Schein erhellt. Dann ein Zoom auf ein Gesicht, und - uuaaahhhh ...
-
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!