Xvid-Video größer als angegeben... Warum ?

Hallo,
1. "Bitrate neu berechnen, wenn nötig habe ich ausgemacht, da ich nicht wollte, das die verändert wird."
Hab schon lange kein GK mehr zum Encoden benutzt, aber Du solltest GK die Bitrate anpassen lassen.
2. Was soll es denn bringen, die Einstellungen vom 1. zum 2. Pass so radikal zu verändern? Ich hab auch gelesen, daß man manche Einstellungen verändern KANN (großartige Anleitung von Selur), aber was hat man davon?
3. Im 2.Pass "Target bitrate in kpbs 2100": Könnte auch die Fehlerquelle sein - lass GK die Zielgröße ausrechnen und den Codec die Bitrate nach dem 1. Durchgang verteilen, dann müßte alles klappen.

Als ich die Zahlen gesehen hab, wollte ich zu erst raten, daß Dein Audio 196kbit hat, aber sind wohl eher 128kbit (ca. 40MB auf ca. 45min)

Hebel mal nicht die Steuerungsmechanismen von GK aus, sondern lass das Programm mal machen. Wenn Du eine Möglichkeit suchst, alles selber einzustellen, dann encode lieber gleich mit VD, da mußt Du dann alles von Hand machen

Schönen Abend!

"Ok vielleicht lieg es auch an meinem Mangel an Kenntnissen über das Xvid Encoding.."
=> 'Wissenswertes rund um Xvid' lesen

"im Xvid Wissen von Seltur stand drinn, dass man das im 1st aus machen kann"
Aber nicht muss

Zitat

5% Overflow bei allen 3"

=>

Zitat

Erhält man z.B. bei 1.1er Versionen des Codec (viel) zu große/kleine Dateien ist es sinnig die drei Werte alle auf 10 zu setzen.

Quelle: Wissenswertes rund um Xvid

-----------

Zitat

daß man manche Einstellungen verändern KANN (großartige Anleitung von Selur), aber was hat man davon?

ISt echt praktisch bei Tests

Cu Selur

Hallo,

ich halte es für Murks, die Overflow-Werte auf 10 zu setzen. Damit wird nur krampfhaft versucht, Frames mit einem Quantizer von 1 zu verwenden und dabei die Dateigröße zu halten. Das macht keinen Sinn für die Qualität, sondern bauscht nur die Dateigröße auf.

Anstatt dessen würde ich im "Quantitazion"-Feld (XviD, Advanced Options) die Mindestquantizer für P- und I-Frames auf 2 setzen, die für B-Frames auf 4. Damit wird die Datei nicht mehr größer als gewollt, sondern kleiner, erreicht aber ihre maximale Qualität.

Warum? Siehe hier.

Gruß

akapuma

Bei der von dir angepeilten Bitrate würde ich von der standardmäßigen H263-Quantisierung auf die MPEG-Matrix umstellen, dann ist auch die Blockartefaktbildung weg und das Bild wirkt wesentlich schärfer.

Also, Didees 6of9 sollte eigentlich auch ein sehr gutes Bild erzeugen...
Ich dachte, Du hättest die H263-Quantisierung benutzt, weil Du oben geschrieben hast "sonst Default".

Zitat

ich halte es für Murks, die Overflow-Werte auf 10 zu setzen. Damit wird nur krampfhaft versucht, Frames mit einem Quantizer von 1 zu verwenden und dabei die Dateigröße zu halten. Das macht keinen Sinn für die Qualität, sondern bauscht nur die Dateigröße auf.

Wenn man Turbo aktiviert wird aber die Standard Curvecompression etwas durcheinander gebracht => man sollte die Overflowwerte anpassen,...

"Das macht keinen Sinn für die Qualität, sondern bauscht nur die Dateigröße auf."
Quantizereinschränken macht für mich viel weniger Sinn.
(vorallem wenn man Custom Matrizen verwendet kann sowas nach hintern losgehen,..)

Cu Selur

Qualität: Was für eine Zielauflösung hast du denn eingestellt? Ich erinnere mich dunkel an das Problem mit oversized Files, bei mir trat das aber nur auf, wenn ich den Codec radikal "unterfordert" habe, d.h. im 2. Pass eine deutlich größere Zielgröße eingestellt hatte, als im 1.Pass rauskam - Was sagt denn der stats-Reader zu dem erstellten stats-File - wie groß war denn der 1. Durchgang?

"1st pass beschleunigen": War das nicht so, daß man diese Einstellungen wählen kann, wie man will, da sie im 1.Pass sowieso abgeschaltet werden? Sorry falls das falsch ist, ist schon ein bischen her, daß ich Selurs Wissenswertes gelesen hab...

Und wo hier grade Selur reinschaut:
In dem Thread steht wieder, daß Q2 optimale Qualität ist. Aber bei Q2 wird ja trotzdem noch gerundet (eben nur mod2), während Q1 ja gar nicht rundet - also ist Q2 doch noch nicht wirklich optimal, oder?

Zitat von Selur

Quantizereinschränken macht für mich viel weniger Sinn.

Wenn ich den Text (siehe mein Link) lese, scheint es doch folgende 3 Fälle zu geben:

1: Quantizer 1 oder 2
2: Quantizer genau 2
3: Quantizer 2 und größer

Eine Maximum-Quantizerbeschränkung macht für mich auch nicht viel Sinn. Aber es macht für mich schon Sinn, denn Fall 1 zu verhindern. Vor den XviD-Versionen 1.x gab es das Problem nicht, da hier die Quantizer schon entsprechend beschränkt waren.

Gruß

akapuma

"Vor den XviD-Versionen 1.x gab es das Problem nicht, da hier die Quantizer schon entsprechend beschränkt waren."
Meiner Ansicht eher da nun leicht andere Datem im 1st pass gesammelt werden (vorallem wenn der Turbo an ist), Quantizer 1 Encodes konnte man ja schon früher machen und da gab es bei mir das Problem auch nicht,...

"also ist Q2 doch noch nicht wirklich optimal, oder?"
Nö, Quantizer 2 wird nur gerne als Optimal bezeichnet, weil der Qualitätsgewinn den Quantizer 1 bringt selten den wesentlich höheren Datenverbrauch rechtfertigt.

"10% heißt ja auch, dass die Datei dann um 10% größer sein kann und das will ich vermeiden."
dann stell Doch 10/5/10 bzw. zumindest die 'Overflow control strength' würde ich erhöhen,...

Cu Selur

@namor84: welche GK Version und welches Xvid verwendest Du?

Hast dich dei Diskussion nicht eigentlich erledigt?
Ich meine wir haben 2 Möglichkeiten gepostet das Problem zu beheben, "Quant capping" und "Overflow Treatment" ändern und wir haben auch kurz über bedenken hinsichtlich der beiden Methoden gesprochen.
=> jetzt liegts an namor84 eine der Methoden zu wählen,...

Cu Selur

1) Schnellere Settings für den 1st-pass sind ja OK. AUSSER (meiner Meinung nach) qpel. Entweder gar nicht, oder in beiden Durchgängen.

Standard-1st-pass deaktiviert zwar auch qpel, aber i.d.Praxis ist das manchmal kritisch: qpel an/aus *kann* die durchschnittliche Frame-Größe sehr stark verändern. Muss nicht, aber kann.

2) Bei "schnellem" 1st-pass (zone @ quant=X, mit schnellen Einstellungen), oder auch bei einem "standard"-1st-pass, hat mal ein vorbeifliegendes Vögelchen etwas von einem

0 - 9 - 4

Overflow-treatment geflüstert. Selber nehme ich gerne 0-8-4.

3) Quant-1 Frames sind'n Witz.

4) Betreffs Quantizer-Beschränkung:

Nur um's mal gesagt zu haben ... weiss nicht, vielleicht bin ich ja der einzige Depp, der noch mit Curve-Compression arbeitet - Jedenfalls: der Effekt (bzw. die Stärke des Effekts), den die Werte für CC verursachen, ist abhängig vom Bereich der erlaubten Quantizer ...

z.B. Bei Quantizern 2-31 ist "CC-high = 40 / low = 20" tödlich. Jedoch, bei max.Quant = ~1.66*avg.Quant sieht das ganz anders aus ...

Moin Didée,

Zitat von Didée

1) Schnellere Settings für den 1st-pass sind ja OK. AUSSER (meiner Meinung nach) qpel. Entweder gar nicht, oder in beiden Durchgängen.

Solche Sachen hatte ich mich auch schon gefragt, aber *BlödFrag* wo stell ich das ein?

Zitat von Didée

3) Quant-1 Frames sind'n Witz.

4) Betreffs Quantizer-Beschränkung:
Nur um's mal gesagt zu haben ... weiss nicht, vielleicht bin ich ja der einzige Depp, der noch mit Curve-Compression arbeitet - Jedenfalls: der Effekt (bzw. die Stärke des Effekts), den die Werte für CC verursachen, ist abhängig vom Bereich der erlaubten Quantizer ...
z.B. Bei Quantizern 2-31 ist "CC-high = 40 / low = 20" tödlich. Jedoch, bei max.Quant = ~1.66*avg.Quant sieht das ganz anders aus ...

Ich glaube, daß mich die beiden Teile interessieren würden, wenn ich sie verstehen würde :redface:
Gehts bei 3 darum, daß man den mod2-Unterschied eh nicht sieht? Das könnte ich verstehen, aber das eine Bit dürfte doch auch nicht so viel kosten...
Und zu 4: Wo könnte man denn das mit der CC (möglichst schnell und schmerzlos) nachlesen?

Zu q1-Frames:

Naja, vielleicht hätte ich besser sagen sollen: in einem 2-pass-Szenario sind q1-Frames ein (schlechter) Witz. In speziellen Fällen hat q1 natürlich schon seine Daseinsberechtigung, z.B. für "fast-verlustlose" Zwischenschritte bei Video-Bearbeitung, Rauschverminderung über multi-Encoding mit Offset, oder was nicht sonst alles.

Aber speziell bei 2-pass macht q1 wenig Sinn.

q1-Frames sind unverhältnismäßig viel größer als q2-Frames. So im Bereich 50% bis 100% größer (hängt sehr stark vom Frameinhalt ab). Als groben Daumenwert nehmen wir einfach mal 70% ...

Typisches Szenario: Neuling macht einen 2-pass, und die gewünschte Endgröße ist 20% größer als der 1st-pass. XviD fängt den 2. pass mit q2 Frames an, es baut sich ein Underflow auf. Bei 25% Underflow muss langsam etwas getan werden, es wird ein q1 Frame gesetzt. Der ist aber zu GROSS, und wegen dem q1-Frame wird der Underflow sofort zu einem Overflow ...
Jetzt gibt's zweieinhalb Möglichkeiten:

a) Overflow Treatment ist passiv eingestellt: XviD kann den von den q1-Frames verursachten Overflow nicht schnell genug kompensieren, deswegen gibt's am Ende ein zu großes File.

b) Overflow Treatment ist aggressiv eingestellt: gibt am Ende die gewünschte Dateigröße, weil XviD den Overflow der q1-Frames auch durch Einsatz von q3-Frames (!) kompensiert. Ein Schildbürgerstreich.

c) Man findet die "richtigen" Werte für Overlow Treatrment (reine Glückssache), oder ... limitiert die Quantizer auf 1-2. Ha ha.

q1 als min.Quant wurde als neuer Default eingeführt, um die Weinerei über Undersizing abzustellen. Jetzt weinen die Leutchen halt über Oversizing ... tolle Verbesserung - Und um das wieder abzustellen, rät man, große Werte für Overflow Treatment einzustellen ... für mich ist das ein ziemlich Kasperlestheater.

Kurz gesagt: der Größenunterschied q1 <--> q2 ist einfach viel zu groß, als dass q1-Frames in einem Encoding mit wechselnden Quantizern sinnvoll eingesetzt werden könnten.
Aus genau diesem Grund hatten wir ja mal mit den sog. "high-bitrate" Matrizen angefangen, damit

a) Qualitäten besser als q2 "praktisch nutzbar" werden, und

b) dem Codec in diesem Bitratenbereich noch eine ausreichend feine Abstufung an nutzbaren Quantizern zur Verfügung steht.

***

Zur Curve Compression ...

... wollte ich eigentlich mal einen Thread aufmachen, weil das Thema irgendwie aus der Welt verschwunden zu sein scheint. Die XviD-Dev's haben mal festgelegt, dass eine "so-konstant-wie-möglich" Verteilung der Quantizer das Nonplusultra ist, und seitdem verwendet niemand mehr Curve Compression.
Eine ordentliche Diskussion, oder auch nur Erläuterung, zur derzeitigen Curve Compression hat es nie gegeben. Auf Anfrage erklär(t)en die Dev's genau das, was in den Tooltips drinsteht. Das ist reichlich magere Information...
Foxer's (im Prinzip bessere bzw. flexiblere, aber inzwischen gecancelte) "alternate Curve Compression" ist damals sehr ausgiebig diskutiert worden, weil viele sie nicht richtig durchschaut haben. Auch ich hab' mich damit schwergetan. Vielleicht mal den Thread auf Doom9 ausgraben.

Jedenfalls:

Zumindest die Werte für "high" Compression sagen NICHT: "so-und-soviel Prozent weniger Bitrate". Kann ja gar nicht sein, dann müssten ja, bei high=100, große Frames ja auf 0 Byte komprimiert werden...
Die "high"-Werte beziehen sich auf den "Qualitätsfaktor". Im allgemeinen Fall spricht man von Q100 = q2 (oder q1?) und Q0 = q31.
Und da kommt die Quantizer-Beschränkung ins Spiel. CC-high = x% bedeutet: x% Annäherung an Q0 für große Frames, wobei aber die "Nullqualität" von Q0 nicht zwingend q31 sein muss. Q0 ist der eingestellte maximal erlaubte Quantizer.

Ob die Werte für "low" Compression Größen- oder Qualitätsbasiert sind, ist mir auch noch nicht klar geworden.

Fallbeispiel, so wie ich gerade "LOST" encodiere:

Mit relativ einfachen Rausch- und Schärfe-Filtern auf 16:9 anamorph aufgeblasen, liegt der avg.Quant (6of9-HVS) so bei 4.5 bis 5.2, je nach Folge.
Fakt ist, die Variabilität des Bitratenbedarfs ist bei LOST sehr groß. Dschungelszenen bei Tage ziehen Bitrate ohne Ende, während die Nacht-Szenen sehr genügsam sind.
Wenn man das jetzt mit der vielgepriesenen "Constant Quality" kodiert, dann ziehen die hi-bit Szenen @ q5 immer noch sehr, sehr viel Bitrate, während die Nacht-Szenen mit q5 schon matschig werden. Die Nachtszenen bräuchten midestens q4, besser q3, um klar zu bleiben. Die Dschungelszenen hingegen würden mit q6 bis q7 immer noch gut aussehen, bräuchten damit aber viel weniger Bits ... was die Verbesserung für die dunklen Szenen überhaupt erst ermöglichen würde.

Und genau das krieg' ich mit 1st-pass @ q4 / VHQ1, und 2nd-pass: limit q3/q8, overflow 0/8/4, hi-CC=35~40, low-CC=16~20, VHQ3. CC-Werte je nach Größe des 1st-pass.