 => Wissenswertes rund um Xvid <= |
Selur
spamming old Newbie
Dabei seit: 13.03.2002
Beiträge: 10.933
 |
|
|
25.05.2004 10:07 |
|
|
|
|
ich sage einfach nur "danke" Selur
cu 
__________________
|
|
|
25.05.2004 13:52 |
|
|
elestrodix
DER Anleitungsmann ;)
Dabei seit: 17.03.2002
Beiträge: 634
Herkunft: Bonner Raum
|
|
Danke auch von mir.
Klasse Anleitung!
__________________
OGM-Overhead-Formel?guckst du hier
|
|
|
26.05.2004 08:58 |
|
|
EthanoliX
Kaiser
Dabei seit: 11.04.2002
Beiträge: 1.310
Herkunft: Mainz
|
|
Yabba dabba doo...
Is' wieder Klasse geworden.
Danke für die Arbeit.
Soviel des Lobes.
Jetzt noch eines zum Bereich "Overflow treatment": XviD akzeptiert bei "Overflow improvement/degradation" scheints den Wert "0" nicht. Zumindest war der Wert, wenn ich 0 eingab, nach dem Encoden, wenn ich das Setup für die nächste Datei erledigte, immer auf 1 gesetzt.
Und bei Deiner Aussage zur "Overflow control strength" ("Wählt man hier einen hohen wert, so wird die Datenrate genauer getroffen, aber die Quantizerverteilung leidet evtl.") bin ich mir nicht sich ob das so stimmt.
Ich meine, daß es bei allen drei Werten des "Overflow treatments" genau anders herum ist:
Je niedriger die Werte, um so dichter liegen die Quantizer beisammen. Bei Werten von 0/1/1 gleicht die Q-Verteilung dann fast derjenigen eines 1pass mit konst. Quantizer. Und gleichzeitig wird die angestrebte Größe sehr genau erreicht.
Ferner ist mein Eindruck, daß bei dieser Vorgehensweise unberücksichtigt bleibt, daß einige Szenen besser und andere schlechter mit höheren Quantizern klarkommen, und daß es deshalb sinnig ist o.g. Werte leicht zu erhöhen, so daß XviD nicht stur nach einen konst.-Quantizer-Mechanismus arbeitet, sondern einigen Abschnitten niedrigere Qs und anderen höhere zuweist. Und dabei kommt es dann bei zu hohen Werten evtl. dazu, daß XviD mit der Dateigröße daneben liegt.
__________________
"Der größte Trick, den der Teufel je gebracht hat, war die Menschheit glauben zu lassen, es gäbe ihn gar nicht."
Roger "Verbal" Kint, Die üblichen Verdächtigen
|
|
|
26.05.2004 11:23 |
|
|
Selur
spamming old Newbie
Dabei seit: 13.03.2002
Beiträge: 10.933
Themenstarter 
|
|
erstmal allgemein zur Klärung:
Xvid hat eine interne 2pass Routine welche die Quantizer an sich so anpssen sollte, dass alle Werte in diesem Bereich eigentlich auf 0 stehen dürften und trotzdem die Quantizer richtig vertielt werden müssten. In der Praxis hat sich allerdings gezeigt, dass die gewünschte Datenrate/Quantizerverteilung nicht immer exakt getroffen wird. Durch die Overflowsettings werden nun einige Settings in dieser 2pass Routine manipuliert, was zwar dazu führt, dass die Datenrate genauer getroffen wird jedoch wird die normale (als ideal angenommene, was sie nicht ist) 2pass routine dadurch in der Datenratenverteilung gestört.
Vorallem nach dem der 1pass in den RC releases einiges flotter wurde, wurde auch die eigentliche 2pass Routine noch etwas ungenauer, als Kompensation sind die Standardwerte von 5% entstanden.
Das die 0 nicht akzeptiert wird ist mir neu, stimmt aber, ist wohl ne Artsicherheitssettings, weil durch den Wert wahrscheinlich im Code geteilt wird.
jetzt zu deinen Aussagen:
| Zitat: |
| Ich meine, daß es bei allen drei Werten des "Overflow treatments" genau anders herum ist: |
Das sehen die Tooltips, die Kommentare der Entwickler und ich aber anders.
| Zitat: |
| Je niedriger die Werte, um so dichter liegen die Quantizer beisammen. Bei Werten von 0/1/1 gleicht die Q-Verteilung dann fast derjenigen eines 1pass mit konst. Quantizer. Und gleichzeitig wird die angestrebte Größe sehr genau erreicht. |
Das kommt sehr stark auf die Quelle an, idealerweise sollte man die Settings nicht brauchen, dann würde es aber keine Oversized und/oder undersized encodes geben, was aber nicht der Fall ist.
| Zitat: |
| Ferner ist mein Eindruck, daß bei dieser Vorgehensweise unberücksichtigt bleibt, daß einige Szenen besser und andere schlechter mit höheren Quantizern klarkommen, und daß es deshalb sinnig ist o.g. Werte leicht zu erhöhen, so daß XviD nicht stur nach einen konst.-Quantizer-Mechanismus arbeitet, sondern einigen Abschnitten niedrigere Qs und anderen höhere zuweist. |
Welche Szene mehr oder weniger Datenrate erhält entscheidet Xvid immer noch selber intern, die Settings beeinflussen nur wie schnell und stark Xvid auf unvorhergesehene Abweichungen seiner vorherigen Schätzungen reagiert.
| Zitat: |
| Und dabei kommt es dann bei zu hohen Werten evtl. dazu, daß XviD mit der Dateigröße daneben liegt. |
Ja, bei zu hohen Werten kann es vorkommen, dass die Manipulation des eigentlichen Grundalgorithmuses zu stark gestört wird.
--
Hoffe meine Erklärung hilft etwas zu verstehen was passiert. Falls noch was unklar ist einfach Fragen.
Cu Selur
__________________
Hybrid
|
|
|
26.05.2004 19:19 |
|
|
EthanoliX
Kaiser
Dabei seit: 11.04.2002
Beiträge: 1.310
Herkunft: Mainz
|
|
| Zitat: |
Original von Selur
...
| Zitat: |
| Ich meine, daß es bei allen drei Werten des "Overflow treatments" genau anders herum ist: |
Das sehen die Tooltips, die Kommentare der Entwickler und ich aber anders.
|
Hmm...
| Zitat: |
| Zitat: |
| Je niedriger die Werte, um so dichter liegen die Quantizer beisammen. Bei Werten von 0/1/1 gleicht die Q-Verteilung dann fast derjenigen eines 1pass mit konst. Quantizer. Und gleichzeitig wird die angestrebte Größe sehr genau erreicht. |
Das kommt sehr stark auf die Quelle an, idealerweise sollte man die Settings nicht brauchen, dann würde es aber keine Oversized und/oder undersized encodes geben, was aber nicht der Fall ist. |
Meiner einer hat oft mit den Overflow-Werten experimentiert, und meine Beobachtung war immer, daß
1. je höher die Werte, desto breiter waren die Quantizer gestreut und
2. je höher die Werte, desto wahrscheinlicher war es, daß die Datei entweder zu klein oder zu groß war.
| Zitat: |
| Zitat: |
| Ferner ist mein Eindruck, daß bei dieser Vorgehensweise unberücksichtigt bleibt, daß einige Szenen besser und andere schlechter mit höheren Quantizern klarkommen, und daß es deshalb sinnig ist o.g. Werte leicht zu erhöhen, so daß XviD nicht stur nach einen konst.-Quantizer-Mechanismus arbeitet, sondern einigen Abschnitten niedrigere Qs und anderen höhere zuweist. |
Welche Szene mehr oder weniger Datenrate erhält entscheidet Xvid immer noch selber intern, die Settings beeinflussen nur wie schnell und stark Xvid auf unvorhergesehene Abweichungen seiner vorherigen Schätzungen reagiert. |
Wie ermittelt XviD eigentlich die erforderlichen Quantizer? Ich glaube da liegt der Hund begraben.
Soweit ich es einschätzen kann (Und ich muß dabei anmerken, daß ich mangels Programmierkenntnisse den Source code noch keines Blickes gewürdigt habe) berechnet der Algorithmus im 1. pass, wie groß die Datei mit Q = 2 würde. Und vor dem 2. Durchlauf wird dann aus der Zielgröße und der Größe mit Q = 2 kalkuliert, wie der mittlere Quantizer sein muß. Und sofern die Overflow-Settings keinen Spielraum zulassen (0/1/1), wird die Datei dann mit dem berechneten mittleren Quantizer erstellt. Dafür spricht, daß bei o.g. Werten meist nur ein (falls der mittlere Quantizer ganzzahlig ist) oder zwei Quantizer (falls nicht) verwendet werden. Interessehaölber habe ich mir mal "live" angeschaut, wie die Quantizer gesetzt werden, und dabei fiel mir auf, daß z.B. bei mittlerem Quant. (p-Frames) von 2,5 die p-Frames mehr oder weniger stur abwechselnd die Quantizer 2 und 3 haben.
Gibt man allerdings andere Werte vor (z.B. 10/30/30), dann werden bei gleicher Zielgröße nicht mehr nur Q = 2 & 3, sondern Q = 1 und auch höhere Werte verwendet (größere Abweichung vom Mittelwert. Und sie werden nicht unbedingt stur abwechselnd verwendet. Und das ist auch die Ursache für das gelegentliche Verfehlen der avisierten Größe: Besteht ein Film z.B. aus zwei ungleichen Hälften, dann kann Xvid am Anfang im z.B. gut komprimierbaren Teil viel einsparen (höhere Quantizer),was dann im 2. Teil zur Qualitätsverbesserung genutzt werden kann (niedrigere Qunatizer). Wenn dann aber nicht alles aufgebraucht wird, kommt es zu undersized Dateien und umgekehrt.
Um es nochmal zusammenzufassen: Mein (naiver) Eindruck ist, daß XviD bei niedrigen Werten stur nach einem mittleren Quantizer arbeitet, und erst durch höhere Werte die Freiheit bekommt der Tatsache Rechnung zu Tragen, daß konst. Quantizer nicht zwangsläufig konstante Qualität bedeuten.
__________________
"Der größte Trick, den der Teufel je gebracht hat, war die Menschheit glauben zu lassen, es gäbe ihn gar nicht."
Roger "Verbal" Kint, Die üblichen Verdächtigen
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von EthanoliX: 27.05.2004 01:10.
|
|
|
27.05.2004 01:03 |
|
|
Selur
spamming old Newbie
Dabei seit: 13.03.2002
Beiträge: 10.933
Themenstarter
|
|
| Zitat: |
1. je höher die Werte, desto breiter waren die Quantizer gestreut und
2. je höher die Werte, desto wahrscheinlicher war es, daß die Datei entweder zu klein oder zu groß war. |
Eine Streung der Qunatizer muss ja nicht flasch sein. Und es sit auch sinnig, dass wenn Du die Werte erhöhst die Quantizer stärker fluktuieren, da Xvid sich schneller an neue Gegebenheiten anpasst und gerade an den sprüngen die Quantizer stark fluktuieren sollten. Hat man einen relativ langsamen Clip mit einigen kutzen Aktionequenzen drinne, so würde Xvid einen mittleren Quantizer ermitteln und möglichst wenige fluktuieren außer in Szenen wo es im 1st pass schon festgestellt hat, dass der Datenratenverbrauch zu hoch ist.
=> im 1st pass versucht Xvid quasi eine Schätzung wie die Quantizer liegen müssen, damit die Datenrate relativ konstant bleibt, sich jedoch nicht zu schnell die Qualität änder wenn es sich vermeiden lässt.
Im 2nd pass wird jetzt anhand dieser Verteilung die Quantizer verteilt und festgestellt, dass manche Szenen sich doch besser/schlechter komprimieren lassen als erwartet. => er ist Datenrate übrig bzw. fehlt. Die Overflowsettings regeln jetzt wie schnell Xvid diese Abweichung wieder unter kontrolle bringen muss. Wo bei die Geschwindigkeit hierbei durch größere Overfloweinträge geregelt wird, die logischer weise dann zu stärkeren Quantizerfluktuationen führt, je höher die Overfloweinträge sind.
| Zitat: |
| Wie ermittelt XviD eigentlich die erforderlichen Quantizer? Ich glaube da liegt der Hund begraben. |
Yup.
"berechnet der Algorithmus im 1. pass, wie groß die Datei mit Q = 2 würde"
stimmt nur noch wenn man einen FullQuality 1st pass macht.
| Zitat: |
| Und vor dem 2. Durchlauf wird dann aus der Zielgröße und der Größe mit Q = 2 kalkuliert, wie der mittlere Quantizer sein muß. |
Ja, wobei dies bedingt auch pro Frame ermittelt wird, es sind also hier schon leichte Fluktuationen eingeplant.
| Zitat: |
| Und sofern die Overflow-Settings keinen Spielraum zulassen (0/1/1), wird die Datei dann mit dem berechneten mittleren Quantizer erstellt. |
Ja, wobei auch fluktuiert wird.
| Zitat: |
| Dafür spricht, daß bei o.g. Werten meist nur ein (falls der mittlere Quantizer ganzzahlig ist) oder zwei Quantizer (falls nicht) verwendet werden. Interessehaölber habe ich mir mal "live" angeschaut, wie die Quantizer gesetzt werden, und dabei fiel mir auf, daß z.B. bei mittlerem Quant. (p-Frames) von 2,5 die p-Frames mehr oder weniger stur abwechselnd die Quantizer 2 und 3 haben. |
Yup, das liegt daran, dass die Verteilugn nicht so clever ist, da es aber funktioniert wird sie nicht groß überarbeitet.
| Zitat: |
| Gibt man allerdings andere Werte vor (z.B. 10/30/30), dann werden bei gleicher Zielgröße nicht mehr nur Q = 2 & 3, sondern Q = 1 und auch höhere Werte verwendet (größere Abweichung vom Mittelwert. Und sie werden nicht unbedingt stur abwechselnd verwendet. |
Ja, was ja an sich nicht verkehrt ist. (Deine Werte sind meiner Ansicht nach für die meisten Clips auch schon zu hoch, würde eher empfehlen die Werte auf 5 zu lassen und nur einen der Werte zu modifiziern.
| Zitat: |
| Und das ist auch die Ursache für das gelegentliche Verfehlen der avisierten Größe: Besteht ein Film z.B. aus zwei ungleichen Hälften, dann kann Xvid am Anfang im z.B. gut komprimierbaren Teil viel einsparen (höhere Quantizer),was dann im 2. Teil zur Qualitätsverbesserung genutzt werden kann (niedrigere Qunatizer). Wenn dann aber nicht alles aufgebraucht wird, kommt es zu undersized Dateien und umgekehrt. |
Und eigentlich sollen die ganzen Overflowsettings gerade regeln wie schnell Xvid sich anpassen kann/muss an etweige Over/Underflows.
| Zitat: |
| Um es nochmal zusammenzufassen: Mein (naiver) Eindruck ist, daß XviD bei niedrigen Werten stur nach einem mittleren Quantizer arbeitet, und erst durch höhere Werte die Freiheit bekommt der Tatsache Rechnung zu Tragen, daß konst. Quantizer nicht zwangsläufig konstante Qualität bedeuten. |
Stimmt in etwa, ich schreib aber nochmal was zu den Features:
Overflow control strength: (Overflow-Kontroll-Agressivität)
Legt fest wie schnell der Codec sich anpassen kann. => hohe Werte hier führen dazu, dass schneller/aggressiver versucht wird den/die 'mittleren' Quantizer/Datenrate zu erreichen. Was zu stärken Fluktuationen führt.
Max overflow improvement: (Maximal- Akzeptierter-Overflow-Aufbau)
Ermöglicht Xvid seltener auszutitschen, wenn die Datenrate mal niedriger ausfällt als erwartet. => Xvid reagiert langsamer auf Wechsel, da es sich um den wachsenden Overflow weniger sorgen macht. => Höhere Werte können zu Undersized files führen, da die Gefahr größer ist, dass der Overflow nicht rechtzeitig abgebaut wird wenn die Overflow control strength nicht hoch genug ist.
Max overflow degration:
Ermöglicht Xvid seltener auszutitschen, wenn die Datenrate mal höher ausfällt als erwartet. => Xvid reagiert langsamer auf Wechsel, da es sich um den wachsenden Underflow weniger sorgen macht. => Höhere Werte können zu Oversized files führen, da die Gefahr größer ist, dass der Underflow nicht rechtzeitig abgebaut wird wenn die Overflow control strength nicht hoch genug ist.
Wo ich das jetzt geschrieben habe, denke ich werde ich den Text im Wissenswertes auch nochmal anpassen, damit er eventuell verständlicher ist.
Cu Selur
__________________
Hybrid
|
|
|
27.05.2004 08:57 |
|
|
EthanoliX
Kaiser
Dabei seit: 11.04.2002
Beiträge: 1.310
Herkunft: Mainz
|
|
Danke für die kleine Diskussion, mal wieder was gelernt.
Aber eine Frage hätte ich noch, was ist "austitschen"? Hab' ich noch nie gehört, und dachte zuerst, es sei ein Schreibfehler.
__________________
"Der größte Trick, den der Teufel je gebracht hat, war die Menschheit glauben zu lassen, es gäbe ihn gar nicht."
Roger "Verbal" Kint, Die üblichen Verdächtigen
|
|
|
27.05.2004 10:00 |
|
|
Selur
spamming old Newbie
Dabei seit: 13.03.2002
Beiträge: 10.933
Themenstarter
|
|
| Zitat: |
| Danke für die kleine Diskussion, mal wieder was gelernt. |
kein Problem, hat mir ja auch gezeigt, dass die alte Formulierung nicht so astrein ist und sollange was bei ner Diskussion rumkommt war sie nicht umsonst.
(Hab ja auch um Kommentare und Kritik gebeten. 
)
'austitschen' ist wohl rheinländisch
Ist sowas wie eine Art überreagieren, wenn sich jemand z.B. unverhältnismäßig reagiert, so sagt man er solle doch nicht so austitschen. Wollte damit sagen, das Xvid sich weniger aufregt, wenn der Over-/Underflow mal höher ist.
(werd den Begriff wohl besser nicht im Wissenswertes verwenden.
)
Kommt wahrscheinlich von: "aus der Reihe titschen" (wie ein Flummi)
Cu Selur
__________________
Hybrid
|
|
|
27.05.2004 10:24 |
|
|
empty
Super Moderator
Dabei seit: 14.04.2002
Beiträge: 1.879
|
|
Eine Sache dazu noch: Xvid berechnet zwar einen mittleren Quantizer aber dieser muss nicht unbedingt häufig zum Einsatz kommen. Kann man sich recht gut anschauen, wenn man mal mit sehr niedriger Bitrate encodet. Dann schwankt der Codec sehr stark und der mittlere Quantizer ist nur ein statistischer Mittelwert. Eventuell hilft es, sich das als Sinusfunktion der Form y=sin(x) +C der Mittelwert ist C aber erreicht wird der Mittelwert nur abundzu (2x pro Periode
). Die Overflowsettings beschreiben nun, wie schnell sich Xvid wieder seiner Idealkurve (in unserem Fall einer simplen Sinusfunktion) annähert. Was mich allerdings wundert, ist die Tatsache, dass die Datei-Größe bei hohen Werten schlechter getroffen werden soll. 
Muss ich mal testen.
BTW: Ich kenne nur eintitschen oder einditschen, z.B. den Zwieback in den Tee o.ä.
Viele Grüße bb empty
__________________
The brain needs oxygen,
so why wear a tie? 
|
|
|
27.05.2004 20:53 |
|
|
Selur
spamming old Newbie
Dabei seit: 13.03.2002
Beiträge: 10.933
Themenstarter
|
|
Es kommt drauf an was hohe Werte hat, wenn der max overlow/degration hoch ist und die Control strenght nicht hoch ist, hab ich sogar erwartet, dass die Filesize nicht getroffen wird.
Cu Selur
__________________
Hybrid
|
|
|
27.05.2004 21:07 |
|
|
Selur
spamming old Newbie
Dabei seit: 13.03.2002
Beiträge: 10.933
Themenstarter
|
|
so jetzt ist die 0.2.1 die aktuelle Version
__________________
Hybrid
|
|
|
21.09.2004 10:19 |
|
|
EthanoliX
Kaiser
Dabei seit: 11.04.2002
Beiträge: 1.310
Herkunft: Mainz
|
|
Schön, daß es mal wieder ein Update gibt.
Fein auch, daß jetzt auch die neuen Features der !.1er Reihe drin sind.
Auf jeden Fall ein 
für die Mühe.
Zwei kleine Anmerkungen noch:
1. Zu GMC, soweit ich weiß bringt VHQ erst ab Level 2 Vorteile für GMC, da bei Level 1 noch keine Bewegungsvektoren gesucht werden.
2. Mit den B-Frame Einstellungen Ratio 1.00 und Offset 0 wäre ich vorsichtig, wenn ich das noch richtig im Kopf habe, dann waren sich Koepi, Teegedeck u.v.a. auf Doom9 sicher, daß mit diesen Einstellungen B-Frames keine Vorteile gegenüber P-Frames hätten.
__________________
"Der größte Trick, den der Teufel je gebracht hat, war die Menschheit glauben zu lassen, es gäbe ihn gar nicht."
Roger "Verbal" Kint, Die üblichen Verdächtigen
|
|
|
21.09.2004 12:30 |
|
|
Selur
spamming old Newbie
Dabei seit: 13.03.2002
Beiträge: 10.933
Themenstarter
|
|
zu 1. kann sein, guck ich mir die Tage nochmal an
zu 2. hängt stark von Auflösung, Datenrate und Material ab das man verwendet, die 1.0&0 sind aber auch nur gedacht um mal zu zeigen, dass man auch was anderes nehmen kann. Auch ist zu beachten, dass bei mir die Anzahl der maximalen B-Frames und die B-Frame sensivity bei diesen Settings dann einiges höher ist als der Standard wert.
=> Werde die Anmerkung aber wahrscheinlich rauswerfen, da sie wohl nicht so aufgenommen wird wie ich es beabsichtigt hatte.
Cu Selur
__________________
Hybrid
|
|
|
21.09.2004 20:36 |
|
|
Dreamer 2002
DVDtoOgm&DVDtoMkv-Team
Dabei seit: 02.05.2002
Beiträge: 3.936
Herkunft: BW
|
|
THX THX THX auch von meiner Seite, immer gern gesehen der Schippass hier
.
Dreamer 2002
|
|
|
21.09.2004 20:45 |
|
|
Selur
spamming old Newbie
Dabei seit: 13.03.2002
Beiträge: 10.933
Themenstarter
|
|
Mist finde es nicht mehr, soweit ich mich entsinne hatte sich mal einer die Mühe bei doom9.org (oder hier?) im Forum gemacht und die PSNR&SSIM Werte von Encodes mit verschiedenen Parametern zu vergleichen und da kam bei rum, dass VHQ1 schonw as gebracht hat.
Cu Selur
__________________
Hybrid
|
|
|
21.09.2004 21:21 |
|
|
Selur
spamming old Newbie
Dabei seit: 13.03.2002
Beiträge: 10.933
Themenstarter
|
|
| RE: => Wissenswertes rund um Xvid - dev4 <= |
     |
Aktuell ist jetzt die 0.2.2
Cu Selur
__________________
Hybrid
|
|
|
20.10.2004 20:39 |
|
|
Selur
spamming old Newbie
Dabei seit: 13.03.2002
Beiträge: 10.933
Themenstarter
|
|
Yup, ist ne gute Idee, werd ich in der nächsten Version bedenken.
Cu Selur
__________________
Hybrid
|
|
|
20.10.2004 21:57 |
|
|
Selur
spamming old Newbie
Dabei seit: 13.03.2002
Beiträge: 10.933
Themenstarter
|
|
0.2.3 ist jetzt aktuell
__________________
Hybrid
|
|
|
08.11.2004 18:12 |
|
|
|
