xvid_encraw probleme

Log Manipulator: Nicht das ich wüsste, aber was willst du denn alles manipulieren, prinzipiell sollte das nicht so schwer sein, sowas zu basteln?

der 1Pass wird immer mit Quant2 gemacht, und daraus wird dann berechnet, wie die Quantizerverteilung im zweiten Durchgang aussehen muss.

Die Logs oben sehen so aus, als ob er schon durchgehend auf quant 2 ginge. Quant 1 hilft praktisch nicht, ist aber große Platzverschwendung. Ist es wichtig, dass die Datei so groß wird, oder sieht sie qualitätsmäßig nicht ordentlich aus?

das time in der ausgabe ist die Zeit, die zum encoden dieses Frames gebraucht wurde, aber da B-Frames ja in falscher Reihenfolge encodet werden, kann es sein, dass der Wert 2 oder auch kein Frame beeinhaltet. Also nicht so arg aussagekräftig.

Was genau verstehst du in den Sourcen nicht?

Zitat von Kopernikus

Log Manipulator: Nicht das ich wüsste, aber was willst du denn alles manipulieren, prinzipiell sollte das nicht so schwer sein, sowas zu basteln?

Ich bin da nur darauf gestossen, als ich noch Probleme hatte bestimmte I-Frames an bestimmten Stellen zu setzen. Deshlab baute ich immer erst die log per Batch um. Da ich nun aber die richtigen Parameter kenne (für Xvid) brauche ich das nun nicht mehr machen. Aber Wünschen würde ich mir so ein Programm schon, damit ich versteh, wie diese Log aufgebaut ist, und was darin was bedeutet. Schade ist nur, das man in encraw nicht einfach IFrame wünsche angeben kann, ohne jetzt wieder ein neues Range zu machen. Deshalb diese Logmanipulation

Denn durch Log Manipulation in DivX konnte ich endlich meine persönlichen IFrames setzen und an bestimmten Stellen, wie in Xvid Ranges machen welches mehr oder weniger Quali brauchen. I-Frames sind an bestimmten stellen sehr wichtig, damit ich AVIs mit genauen Kapitelsprüngen erzeugen kann. Welches auch in MP4 sehr nützlich ist.

Zitat von Kopernikus

der 1Pass wird immer mit Quant2 gemacht, und daraus wird dann berechnet, wie die Quantizerverteilung im zweiten Durchgang aussehen muss.

aha

Zitat von Kopernikus

Die Logs oben sehen so aus, als ob er schon durchgehend auf quant 2 ginge. Quant 1 hilft praktisch nicht, ist aber große Platzverschwendung. Ist es wichtig, dass die Datei so groß wird, oder sieht sie qualitätsmäßig nicht ordentlich aus?

Erst ging es mir darum, auf eine bestimmte Dateigröße zu kommen, die ich aber nie erreichte, weil maximal Quant 2 gemacht wurde. Durch div. Tests und sichtvergleiche, bemerkte ich, wenn man auch Quant 1 erlaubt, das das bild irgendwie besser und ruhiger auf dem Standalone lief. Deshalb erlaube ich immer dieses Quant 1.

Weil ich gestern abend den Ziel size falsch eingetragen hatte, wurde mir ein xvid mit Quant 1 und einer Bitrate von 8MB/s erzeugt. Daraufhin erzeugte ich mal ein neues mit Quant 1 aber ohne Bitratenwunsch und diese war viel kleiner. Was ist da jetzt der unterschied? Dachte immer Quant 1 ist die maximale Qualität?

Zitat von Kopernikus

Was genau verstehst du in den Sourcen nicht?

naja ich wollte rausfinden, welche min und max Werte zu div Parametern es gibt.[INDENT]zb bei -zw starting_frame float (bitrate zone; weight) Wenn man da einen Wert von -zw 500 0 angibt,scheint encraw dies zu übergehen und erst ab 0.01 die Bitrate runterzusetzen.
[/INDENT]
genauso weis ich nicht, welche Werte bei anderen ( -clow, -ostrength etc ) möglich sind. verstehste?

EDIT: Nachfrage: was passiert eigentlich, wenn man bei einem Clip von 30000Frames nur vier IFrames drin hat? schön man kann nicht sauber spulen, aber so wie ich das verstanden habe, um so mehr I-Frames vorhanden um so mehr Bitrate wird verbraucht oder die Qualität sinkt. stimmt des ?

Zitat von katjarella

Denn durch Log Manipulation in DivX konnte ich endlich meine persönlichen IFrames setzen und an bestimmten Stellen, wie in Xvid Ranges machen welches mehr oder weniger Quali brauchen. I-Frames sind an bestimmten stellen sehr wichtig, damit ich AVIs mit genauen Kapitelsprüngen erzeugen kann. Welches auch in MP4 sehr nützlich ist.

Also bei einem kurzen Drüberschauen scheint es mir so, als ob es im Prizip nicht schwer sein sollte I-Frames zu erzwingen, indem man den ersten Buchstaben in der entsprechenden Zeile im statsfile ändert (habs kurz getestet, scheint zu funktionieren). Das sollte dafür sorgen das ein I-Frame gesetzt wird. Wie verlässlich dann die Ratecontrol noch arbeitet, kann ich nicht einschätzen, das müsste man testen. Es ist vermutlich besser, wenn man I-Frames nur verschiebt, und nicht zusätzlich einfügt, und hofft, dass die RC das gut genug kompensiert, was sich durch die anderen Frametypen ändert.

Man könnte also im Prinzip einen komfortablen Log Editor basteln. Das Logfile ist so aufgebaut:
jede Zeile ein Frame
Buchstabe: Frametyp
Zahl: Quantizer
Zahl: intra Blocks in diesem Frame
Zahl: inter Blocks in diesem Frame
Zahl: skip Blocks in diesem Frame
Zahl: Anzahl Byte für dieses Frame
Zahl: Anzahl Bytes Overhead, also Bytes für Dinge die durch niedrigere Quantizer nicht kleiner werden.

Zitat von katjarella

Erst ging es mir darum, auf eine bestimmte Dateigröße zu kommen, die ich aber nie erreichte, weil maximal Quant 2 gemacht wurde. Durch div. Tests und sichtvergleiche, bemerkte ich, wenn man auch Quant 1 erlaubt, das das bild irgendwie besser und ruhiger auf dem Standalone lief. Deshalb erlaube ich immer dieses Quant 1.

Weil ich gestern abend den Ziel size falsch eingetragen hatte, wurde mir ein xvid mit Quant 1 und einer Bitrate von 8MB/s erzeugt. Daraufhin erzeugte ich mal ein neues mit Quant 1 aber ohne Bitratenwunsch und diese war viel kleiner. Was ist da jetzt der unterschied? Dachte immer Quant 1 ist die maximale Qualität?

Im Prinzip ja, aber es gibt noch einige andere Einstellungen die Größe und Qualität beeinflussen. Waren die Einstellungen sonst gleich?

Zitat von katjarella

naja ich wollte rausfinden, welche min und max Werte zu div Parametern es gibt.[INDENT]zb bei -zw starting_frame float (bitrate zone; weight) Wenn man da einen Wert von -zw 500 0 angibt,scheint encraw dies zu übergehen und erst ab 0.01 die Bitrate runterzusetzen.
[/INDENT]
genauso weis ich nicht, welche Werte bei anderen ( -clow, -ostrength etc ) möglich sind. verstehste?

Was sollte XviD denn bei einer Gewichtung von Null machen? So klein wie möglich?

Das er nichts ändert hängt damit zusammen, wie das intern gehandhabt wird.

Edit:

Zitat von katjarella

EDIT: Nachfrage: was passiert eigentlich, wenn man bei einem Clip von 30000Frames nur vier IFrames drin hat? schön man kann nicht sauber spulen, aber so wie ich das verstanden habe, um so mehr I-Frames vorhanden um so mehr Bitrate wird verbraucht oder die Qualität sinkt. stimmt des ?

Jein. 30000 Frames und 4 I-Frames ist wirklich wenig. I Frames haben ihre Berechtigung, weil es besser sein kann, ein Frame komplett Intra zu codieren, als aus dem vorherigen zu bewegungskompensieren (beispiel Szenenwechsel, da die Frames unterschiedlich sind, kann man keine bewegungskompensierung machen). Ausserdem ist ASP nicht bitexakt spezifiziert, da es mit nicht-Ganzzahlen arbeitet, und verschiedene Architekturen unterschiedlich genaue Gleitkommarechnungen durchführen können, sondern es ist nur eine bestimmte genauigkeit verlangt. Deshalb können sich Rundungsfehler aufschaukeln. Es wird sogar IIRC im Standard gefordert, dass jeder Block nur eine bestimmte Anzahl an Frames nicht-Intra codiert werden darf.

Aber I-Frames sind größer als P/B Frames, deshalb sind zuviele davon auch nicht gut.

Zur letzten Frage:

Es wird immer leichte Rundungsfehler geben. Je länger eine GOP ist, umso länger können sich Rundungsfehler (und Datenfehler im Material durch fehlerhafte Übermittlung) allerdings auch aufschaukeln, und werden beim nächsten I-Frame dann vielleicht mit einem sichtbaren Sprung korrigiert.

Wenn du Beispiele brauchst, kann ich gern was liefern. Es gab da mal Unterschiede in der Implementierung zwischen DivX 5.01/5.02 und DivX 5.03+ - die ergeben zwar nicht exakt den selben Effekt, aber veranschaulichen ihn schön übertrieben. Im englischen doom9-Board hatte ich das als "orange-blue bug" für ffdshow dokumentiert (ffdshow hatte mal für kurze Zeit die Kompatibilitäts-Unterstützung für DivX-5.01/2-Material deaktiviert).

Thema komfortablen Log Editor basteln:

hier mal ein Shot nach der DivX Analyse (1pass):
[Blockierte Grafik: http://img151.imageshack.us/img151/5630/ekgdivx1qo3.th.jpg]

dann mit manueller Bearbeitung ( inc. div. I-Frame löschung):
[Blockierte Grafik: http://img151.imageshack.us/img151/8282/ekgdivx2fh8.th.jpg][Blockierte Grafik: http://img151.imageshack.us/img151/416/ekgdivx3bs5.th.jpg]

Da DivX einen nPass Modus hat, ließt er dann die manipulierte Log und verteilt es dann nochmal ein bissl besser. (shot kommt dann, encode gerade etwas anderes)

------------------------------------------------------------
Thema: Gewichtung von Null machen? So klein wie möglich?
Ja

------------------------------------------------------------
Thema: Danke für die Info. Das mit dem Verschieben, kann ich leider nicht, dazu fehlt mir das Hintergrundwissen. Aber dann werde ich lieber mal meinen Parameter -kill ( killkeyframes = true ) auf Eis legen Und schon vorher die I-Frames von 250 auf 500 setzen.

------------------------------------------------------------

LigH
ich encode nur noch mit v6.x weil ich dort directes CLI Encoding machen kann ohne die Registry "patchen" zu müssen.

-bvn1f 4000000 -vbv 4854000,3145728,2359296 -dir "%WORK%" -w -pq 8610 -b 0 -profile=3 -quantization=1 -enable_feedback=0 -thread_delay=1

was macht dein Kill Parameter?

Wegen -zw frame 0:

Ich hab mal einen kurzen Patch an die Mailingliste geschickt, der das Verhalten behebt, und -zw frame 0 mit quant 31 zu encoden. Da die Mailingliste in letzter Zeit sehr ruhig ist, weiß ich nicht, ob und wann das in CVS einfließt.

-kill: lösche alle I-Frames raus und wenn es kein -iframes Parameter in der commandline gibt, blieb wenigstens der erste I-Frame übrig.

-------------------------------------------------

-zw frame 0: feine sache.

-------------------------------------------------

LigH
tut mir leid, CLI Encoding ging ja wirklich schon ab v5.x :rot_schaem:

GordianKnot hat ja schon einen stats-Editor eingebaut. Der allerdings noch auf DivX-3-Level. Oder wurde der aktualisiert?

Dazu muss man allerdings in den Optionen die erweiterte Ansicht "nicht verstecken".

Schaut auch mal unbedingt hier : https://gleitz.info/wiki/index.php/XVID_encraw

wie kann ich bei Xvid(_encraw) erreichen, das er genau alle 250 Frames ein I-Frame macht? Denn -max_key_interval 250 reicht hier nicht aus.

Wenn man bei DivX, Maximum Key Frame interval = 250 und Scene Change Thereshold = 100 macht, habe ich alle 250 Frames ein I-Frame.

Das sinnigste ist vermutlich jede 250 Frames eine Zone zu erstellen,..

Cu Selur

Erst wenn alle I/B/P-Frames an der gleichen Position sind kann man doch DivX und Xvid richtig vergleichen. Und der max Iframe reicht dazu einfach nicht, weil dazwischen wieder irgendwelche IFrames gestreut werden.

gibt in xvid_encraw keinen Parameter in diese Richtung?

ach und wie sehen eigentlich die Sourcen (Formel) aus, wie die Berechnung der Bitrate ist, wenn man -size angibt. denn das doofe ist man gibt in kb an und bekommt am Schluß den Size in Byte raus

Zitat von katjarella

genau alle 250 Frames ein I-Frame macht? Denn -max_key_interval 250 reicht hier nicht aus.

Dazu bräuchtest du wohl sowohl "-max_key_interval 250" als auch "-min_key_interval 250".

Zitat

Erst wenn alle I/B/P-Frames an der gleichen Position sind kann man doch DivX und Xvid richtig vergleichen.

Wer behauptet denn sowas? Das macht meiner Ansicht nur Sinn, wenn der Vergleich nur auf einem Frame-to-Frame vergleich basiert.

Meiner Ansicht nach entscheidet der Codec wann er welches Frame setzt, wenn er dadurch Nachteil erleidet weil er einen Fehler macht, dann ist das eine Schwäche des Codecs.

LigH: Welche Xvid_encraw Version nutzt Du? Bei den Versionen die ich hier so habe gibt es keinen Parameter um ein minimales I-Frame Intervall festzulegen,.... (soweit mir bekannt)

Cu Selur

hallo Jungs, ich habe auf einmal einen Warnhinweis:

Zitat

xvid [warn]: Can't find xvid_plugin_ssim, ssim calculations will be disabled

auf der Suche dazu bin ich auf Kopernikus Seite gestossen und mir xvid_encraw_hvs_061119 runtergeladen. Jedoch kann es nur AVIs im YV12 lesen, aber das geht im HFYU leider nicht.

Die HuffYUV-Implementation in ffdshow (ffdshow VfW Codec) kann YV12-HFYU erzeugen.

wenn du die SSIM Berechnung nicht brauchst, dann kannst du den Warnhinweis einfach übergehen.

Sonst brauchst du eine aktuelle CVS xvidcore.dll, da ist der SSIM Code bereits drin.

Danke für die Informationen, muß aber einen anderen Weg einschlagen und das HFYU nur für AVISynth-Random Test benutzen.

------------------------------------------
noch zwei andere Sachen:
1: die Angezeigt *** encoded, 13.04 fps, Average ***, kann nicht stimmen.

2: Als ich jetzt vom Schlittenfahren zurück kam, wunderte ich mich schon über die kleine AVI Datei Größe:

Source:  * Filename: "***\SME02_PAL_DVD.avs"  * FourCC: YUY2  * [COLOR='Lime'][B]Frames: 15440[/B][/COLOR]  * Resolution: 720x576  * Frame rate: 25.000 FPSCompressor:  * Name: Huffyuv v2.1.1 - CCESP Patch v0.2.5  * FourCC: HFYUDestination:  * Filename: "***\SME02_PAL_DVD_HFYU.avi"  * Pass 1/1: Finished in 01:08:58.031 (3.73 FPS)  * [B][COLOR='#00ff00']Frames: 15440[/COLOR][/B] (15440 keyframes)  * Size: 3244.39 MBxvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert 2002-2003xvid [warn]: Can't find xvid_plugin_ssim, ssim calculations will be disabledTrying to retrieve width and height from input headerxvid [info]: Input colorspace is YUYV or YUY2xvid [info]: Input is 720 x 576, 25.000fps (25/1), starting from frame 0xvid [info]: Number of frames [B][COLOR='#00ff00']to encode: 15440[/COLOR][/B]xvid [info]: xvidcore build version: xvid-1.1.2xvid [info]: Bitstream version: 1.1.2xvid [info]: Detected CPU flags: ASM MMX MMXEXT SSE SSE2 TSCxvid [info]: Detected 0 cpus, using 0 threads.   [B][COLOR='Red']9601 frames( 62%) encoded[/COLOR][/B],  21.14 fps, Average Bitrate =  2738kbpsTot: enctime(ms) =454524.00,               length(bytes) = 131473688Avg: enctime(ms) =  47.30, fps =  21.14, length(bytes) =   13680I frames:     74 frames, size =   40037/2962759, quants =  2 / 2.00 /  2P frames:   3700 frames, size =   27281/100942759, quants =  2 / 2.00 /  2B frames:   5834 frames, size =    4725/27568170, quants =  4 / 4.00 /  4xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert 2002-2003xvid [warn]: Can't find xvid_plugin_ssim, ssim calculations will be disabledTrying to retrieve width and height from input headerxvid [info]: Input colorspace is YUYV or YUY2xvid [info]: Input is 720 x 576, 25.000fps (25/1), starting from frame 0xvid [info]: Number of frames [B][COLOR='#00ff00']to encode: 15440[/COLOR][/B], Bitrate = 850kbpsxvid [info]: xvidcore build version: xvid-1.1.2xvid [info]: Bitstream version: 1.1.2xvid [info]: Detected CPU flags: ASM MMX MMXEXT SSE SSE2 TSCxvid [info]: Detected 0 cpus, using 0 threads.   [B][COLOR='#ff0000']9601 frames( 62%) encoded[/COLOR][/B],  11.13 fps, Average Bitrate =   843kbpsTot: enctime(ms) =862851.00,               length(bytes) = 40495806Avg: enctime(ms) =  89.79, fps =  11.14, length(bytes) =    4213I frames:     74 frames, size =   20062/1484617, quants =  2 / 4.54 /  6P frames:   3700 frames, size =    7425/27475434, quants =  2 / 5.89 /  7B frames:   5834 frames, size =    1977/11535755, quants =  4 / 9.31 / 11

kann es sein, das xvid_encraw nicht das ganze HFYU.avi von 3244.39 MB lesen kann? Denn ich habe mein EncodeScript mal abgeändert und noch einen zwischen Schritt eingefügt, das er noch ein AVS Script schreibt.

AVISOURCE("SME02_PAL_DVD_HFYU.avi")ConvertToYV12()

xvid [warn]: Can't find xvid_plugin_ssim, ssim calculations will be disabled
Trying to retrieve width and height from input header
xvid [info]: Avisynth detected
xvid [info]: Input colorspace is YV12
xvid [info]: Input is 720 x 576, 25.000fps (25/1), starting from frame 0
xvid [info]: Number of frames [B][COLOR='Lime']to encode: 15440[/COLOR][/B]
xvid [info]: xvidcore build version: xvid-1.1.2
xvid [info]: Bitstream version: 1.1.2
xvid [info]: Detected CPU flags: ASM MMX MMXEXT SSE SSE2 TSC
xvid [info]: Detected 0 cpus, using 0 threads.
  [B][COLOR='RoyalBlue']15426 frames( 99%) encoded[/COLOR][/B],  24.61 fps, Average Bitrate =  3010kbps
Tot: enctime(ms) =627233.00,               length(bytes) = 232193193
Avg: enctime(ms) =  40.62, fps =  24.62, length(bytes) =   15036
I frames:    [B][COLOR='#4169e1']142[/COLOR][/B] frames, size =   39009/5539318, quants =  2 / 2.00 /  2
P frames:   [B][COLOR='#4169e1']6192[/COLOR][/B] frames, size =   29369/181855481, quants =  2 / 2.00 /  2
B frames:   [B][COLOR='#4169e1']9106[/COLOR][/B] frames, size =    4919/44798394, quants =  4 / 4.00 /  4

== 15440

Das könnte schon sein. Vermutlich verwendet squids encraw VfW zum decodieren von nicht avisynth avis, und da wäre es durchaus möglich, dass es ohne Workarounds Probleme mit avis > 2GB gibt.