• Zitat


    Soweit ich mich entsinne-Ja!

    Es ist definitiv so, ich hab die entsprechende Stelle gefunden.

    Ich hab auch das Problem gelöst. Ich weiß zwar nicht genau wie, aber auf jeden Fall funktioniert es jetzt. Ich vermute, dass irgendwelchen Überreste von verschiedenen Konpilierdurchgänge sich verwurstelt haben. Ein grundsätzlicher Rebuild hat es auf jeden Fall gelöst.

    Wie immer hier:
    http://web3.gleitz.org/Kopernikus/XviD110beta2mod3.zip

    (Ich hoffe wirklich, dass es jetzt alles passt :) )

    Es gibt eine Theorie, die besagt, dass das Universum sofort verschwinden und etwas noch Unerklärlicheres und Bizarres an seine Stelle treten wird, sobald jemand herausfindet, wofür es gut ist und warum es existiert.

    Es gibt eine andere Theorie, die besagt, dass das bereits geschehen ist.

  • > Ich habe die MPEG4 ASP Specs jetzt nicht zur Hand,

    ich habe sie nie zur hand gehabt, aber ich habe genuck mit MPEG4(a)sp codecs gespielt um eine gute idee zu haben ;)

    >aber ich vermute, dass adaptive Quantisierung auch mit einem Syntaxelement im Macroblock Layer gemacht wird. Ist das richtig?

    ja .. ich wird es später erklären.

    >Zu 1.+2. Dieses Lambda wird so gewählt, dass Pixel, bei denen der Fehler sichtbarer ist ein größeres Lambda bekommen, und Pixel, bei denen der Fehler nicht so sichtbar ist, ein kleineres Lambda. Hab ich das so richtig verstanden?

    ja

    >Dann ist es eher der Fall, dass XviD einen Modus wählt, der mehr Distortion aber weniger Rate hat.

    modus, bewegung vectoren, trellis quant, ect ... alle die whäle die R-D optimisiert sind. XviD benutzt ein lambda von ein lamda = f(quant) formel, aber andere lambda könnten benutzt werden.

    >Da müsste man also quasi ein Lambda Table für jeden Block (oder Macroblock oder Pixel) haben (falls es das nicht schon irgendwo gibt), und dieses dem HVS Modell entsprechend abändern.

    ja. Dass wär, was syskin mit HVS-plugin machen wollte ... but es wahr nie implementiert.

    >Das Problem ist nur, dass ich nicht genau weiß ob ich das auch programmieren kann. Bei AQ ist das relativ einfach, weil der ganze Code an einer Stelle ist, recht übersichtlich, und ich nur die Formel ändern muss Aber ich kann mich mal in den Code stürzen, vielleicht wird es was.

    vielleicht... ich denke AQ ist so suboptimal dass es zu schwierich etwas überall gutes zu machen.

    > BTW: "pruned trees" werden doch bei Wavelets verwendet, oder?

    man kann 'prune' viele verschidene 'trees' :)
    es gebt keine tiefe grund dass ich diese nick benutze, aber ich bin keine wavelets fan : DCT mit lapping/TDAC (time domain aliasing cancellation) kann das selbe performance reichen, ist schneller, und ich finde es eleganter ^^

    > Kann es sein, dasa AQ nur bei P und I Frames, nicht aber bei B-Frames greift.

    ja.
    AQ kann in allen vops benutzen werden (aber für B-vops ist es nicht in XviD implementiert, und es ist nich gerade das selbe)
    die MB-modus fur I,P und S vops sind die selben, in XviD : INTRA, INTRA_Q, INTER, INTER_Q, INTER4V, NOT_CODED genannt.
    INTRA_Q ist wie INTRA, und INTER_Q ist wie INTER, aber mit ein dquant symbol. als ihr sehen können, beide INTER4MV und AQ können nich gleichzeitich gewhält werden ... und INTER4MV ist sehr benutz ^^

    AQ ist durch das dquant symbol implementiert. Das dquant symbol is zwei bits lang, so AQ kann nucht currentQ bei -2/-1/+1/-2 ändern. zwei bits kann sehr teuer sein, und es ist hart zwischen 4mv und AQ zu wälhen... und die qualität sprunch zwischen verschidenen quantizern wenn mann ein höher bitrate hat sind zu gross (q2-3-4 zum Beispiel)

    Ich denke das RDO model weiter zu mitbringen ist dass bestest weg, und MPEG4avc besser fur HVS tweaks als HVS MPEG4asp ist.

  • prunedtree: Weißt du zufällig, wo in den XviD Sourcen die RDO implementiert ist? Ich habe einen Teil davon gefunden, aber ich glaube irgendwie, dass das nicht alles ist.

    @all
    so, ich hab nochmal geupdatet, jetzt funktioniert es wirklich (hab mal wieder ein + und ein - verwechselt gehabt, und jetzt den Grund gefunden, weshalb es beim letzten mal nicht funktioniert hat.)

    http://web3.gleitz.org/Kopernikus/XviD110beta2mod3.zip

    Es gibt eine Theorie, die besagt, dass das Universum sofort verschwinden und etwas noch Unerklärlicheres und Bizarres an seine Stelle treten wird, sobald jemand herausfindet, wofür es gut ist und warum es existiert.

    Es gibt eine andere Theorie, die besagt, dass das bereits geschehen ist.

  • Jawoll, jetzt funktioniert's :)

    Hab' mal einen Test mit einer dunklen Szene aus LOTR-TTT gemacht, 3 1/2 Minuten lang. avg. Luma ist durchgängig unter 90, so gut wie ohne helle Flecken - d.h. es wird durchgehend inverses AQ verwendet, und kein standard-AQ (zumindest fast nicht).

    mit 6of9 @ q4 / B=q6:

    kein iAQ: 51630 kB
    mit iAQ: 59226 kB

    also knapp 15% mehr ... meine Schätzung war also gar nicht schlecht, eher sogar zu pessimistisch.
    Ach so: und besser aussehen tut's tatsächlich auch noch, darum geht's ja.

    zum Vergleich: die gleiche Szene mit q3 (B=q5) - also der Fall, wenn man im 2-pass manuell per 'zone' mehr Bitrate erzwingen würde: 69714 kB, plus 35%.

    So ganz abwegig ist die Methode also grundsätzlichschon mal nicht. Es scheint als ob der gewünschte Effekt erzielt werden kann, und vor allem geschieht es "automatisch", ohne dass man erst mal ein vollständiges Encoding macht, sich dieses genau anschaut, die Szenen notiert wo der Teufel der Dunkelheit zugeschlagen hat, sodann viele Zonen manuell einrichtet, und das ganze nochmal encoded ... :hm:

    Jetzt würd' ich gerne verschiedene Quellen unter die Lupe nehmen und analysieren, für welche Luma-Bereiche von Frames welche Block-Lumawerte tatsächlich typischerweise am kritischsten sind, um die Verringerung der Block-Quantizer so günstig wie möglich zu plazieren. (Das kann aber ein wenig dauern.)

    Allerdings:

    Zitat von prunedtree

    als ihr sehen können, beide INTER4MV und AQ können nich gleichzeitich gewhält werden ..

    Oha! Sowas muss man natürlich erst einmal wissen! Das reduziert natürlich die praxistauglichkeit von AQ, nicht ganz unerheblich.

    Wie ist das: Wird eine dynamische Entscheidung getroffen, ob für den aktuellen Block inter4mv oder AQ günstiger ist? Oder wird nur getestet, ob inter4mv für den aktuellen Block verwendet wird ... und wenn nicht, dann kann gegebenenfalls AQ verwendet werden?

  • Was lange währt wird endlich gut :)

    Freut mich, dass es funktioniert.

    Es gibt eine Theorie, die besagt, dass das Universum sofort verschwinden und etwas noch Unerklärlicheres und Bizarres an seine Stelle treten wird, sobald jemand herausfindet, wofür es gut ist und warum es existiert.

    Es gibt eine andere Theorie, die besagt, dass das bereits geschehen ist.

  • Zitat von Kopernikus

    Was lange währt wird endlich gut :)

    Freut mich, dass es funktioniert.

    Hab mich grad für's deutsche Forum registriert. Hallo miteinander :)

    Wie gut würde AQ mit höheren Quants funktionieren?
    Ich frage weil ja bei Q3 encodes +-1 enorm viel ist. Also was ist mit ner CQM die alle Werte halbiert oder drittelt und damit den quant Bereich 2..6 der oft verwendet wird nach 4..12 bzw. 6..18 abbildet. Dann ist der Einfluss von AQ besser steuerbar.

    bis besser,
    T0B1A5

    Diese Signatur steht zum Verkauf

  • Welcome, Tobias! (oder muss es die Nummer sein?) ;)

    Gute Idee. Warum hab ich SixOfNine, kurz 6o9, kreiert? Weil ich (m)eine Matrix mit kleineren Quantisierungsschritten haben wollte. Vor allem für die "teuren" Bitratenbereiche q2~q4 der Standard-Matrix. 6o9 bildet q2-q4 etwa auf q3-q6|q7 ab (geht nach oben nicht linear). Damit lässt sich alles besser steuern - Bitrate generell, B-Frame-Offsets, und eben auch AQ. (Und wenn's sein muss, mit q2 ein brauchbarerer Notfallplan als q1 der Standard-Matrix.) ;)

  • Aber vermutlich fallen bei höheren Quants die zusätzlichen 2 Bit pro Macroblock stärker ins Gewicht.

    Es gibt eine Theorie, die besagt, dass das Universum sofort verschwinden und etwas noch Unerklärlicheres und Bizarres an seine Stelle treten wird, sobald jemand herausfindet, wofür es gut ist und warum es existiert.

    Es gibt eine andere Theorie, die besagt, dass das bereits geschehen ist.

  • Nö, das eigentlich nicht. Ob irgendeine Bitrate, z.B. 1234kbps, mit Quantizer 3 (normale Matrix) oder mit Quantizer 5 (hi-BR Matrix) erreicht wird, ist in dieser Hinsicht egal - die Kosten für dquant bleiben die gleichen.
    Was sich u.U. ändern kann, ist die ME. Syskin hat mal gesagt, dass für höhere Quantizer der Suchbereich, also die maximale Vektorlänge, eingeschränkt wird. Das macht sich aber erst in viel höheren Quant-Bereichen wirklich bemerkbar.

  • Ok, ich hab mich unklar ausgedrückt. Was ich meinte, dass wenn bei deutlich höheren Quants ein P- oder B-Frame nur noch wenige kB groß ist, der Platz, den AQ verbraucht, sinnvoller angelegt sein werden.

    Es gibt eine Theorie, die besagt, dass das Universum sofort verschwinden und etwas noch Unerklärlicheres und Bizarres an seine Stelle treten wird, sobald jemand herausfindet, wofür es gut ist und warum es existiert.

    Es gibt eine andere Theorie, die besagt, dass das bereits geschehen ist.

  • Zitat von Kopernikus

    Ok, ich hab mich unklar ausgedrückt. Was ich meinte, dass wenn bei deutlich höheren Quants ein P- oder B-Frame nur noch wenige kB groß ist, der Platz, den AQ verbraucht, sinnvoller angelegt sein werden.

    Yo, das ist einer der wesentlichen Nachteile von AQ (das meinte prunedtree ja auch). Deshalb ist es sinnvoller Lumimasking ueber veraenderte DCT Koeffizienten einzufuehren wie es in DivX der Fall ist, allerdings auch mit etwas mehr Aufwand verbunden ist...

    ps.
    hi Tobias

  • Zitat

    Yo, das ist einer der wesentlichen Nachteile von AQ (das meinte prunedtree ja auch). Deshalb ist es sinnvoller Lumimasking ueber veraenderte DCT Koeffizienten einzufuehren wie es in DivX der Fall ist, allerdings auch mit etwas mehr Aufwand verbunden ist...

    Ich hab die entsprechenden Funktionen gefunden, vielleicht schraub ich mal ein bisschen an der RDO. Aber die nächste Woche hab ich nicht so Zeit. Naja mal sehen.

    P.S.: Grad ist im x264 IRC ein AQ Patch von Haali aufgetaucht.

    Es gibt eine Theorie, die besagt, dass das Universum sofort verschwinden und etwas noch Unerklärlicheres und Bizarres an seine Stelle treten wird, sobald jemand herausfindet, wofür es gut ist und warum es existiert.

    Es gibt eine andere Theorie, die besagt, dass das bereits geschehen ist.

  • Zitat

    P.S.: Grad ist im x264 IRC ein AQ Patch von Haali aufgetaucht.

    Naja gibt blauen Flaechen nur nen paar mehr bits (find ich zwar gut aber berauschend ist ist es ja nicht unbedingt). Vielleicht sollte er noch dunkelrote Teile des Bildes miteinbeziehen und dort ebenfalls mehr bits geben. Staerkere Deblocking Thresholds fuer rote und blauche Flaechen koennten auch helfen.

  • Naja immerhin. Ausserdem kann das immernoch verfeinert werden...

    edit:
    z.B. könnte man Lumimasking sehr einfach einbauen, weil die Blockhelligkeit schon berechnet wurde, als die Blockdaten transformiert wurden, da muss man sich nur noch den DC Koeffizienten rauspicken.

    Man kann die Deblocking Thresholds nur für ganze Slices ändern, nicht für einzelne Macroblocks.

    Es gibt eine Theorie, die besagt, dass das Universum sofort verschwinden und etwas noch Unerklärlicheres und Bizarres an seine Stelle treten wird, sobald jemand herausfindet, wofür es gut ist und warum es existiert.

    Es gibt eine andere Theorie, die besagt, dass das bereits geschehen ist.

  • Hat eigentlich jemand (ausser mir) mal die Contrast Masking Version getestet, und kann einen Kommentar dazu abgeben?

    Und ich hätte noch eine Frage. Könnte jemand ein Kurzes Stück (150-300 Frames) Anime zur Verfügung stellen, damit ich damit testen kann? Ich besitze selber soetwas nicht.

    Es gibt eine Theorie, die besagt, dass das Universum sofort verschwinden und etwas noch Unerklärlicheres und Bizarres an seine Stelle treten wird, sobald jemand herausfindet, wofür es gut ist und warum es existiert.

    Es gibt eine andere Theorie, die besagt, dass das bereits geschehen ist.

  • Ich liebe ja jeden Fortschritt den XviD macht, aber wäre es nicht allgemeingültiger einen HVS basierten RD Modus einzubauen?

    Soweit ich weiss betrachtet SSIM auch Helligkeiten und Kontraste.

    Noch ne prinzipielle Frage: Darf man in ASP jeden Block beliebig quantisieren oder gibt es nen maximalen Abstand zum frame quant?

    bis besser,
    T0B1A5

    Diese Signatur steht zum Verkauf

  • Zitat

    Ich liebe ja jeden Fortschritt den XviD macht, aber wäre es nicht allgemeingültiger einen HVS basierten RD Modus einzubauen?

    Soweit ich weiss betrachtet SSIM auch Helligkeiten und Kontraste.

    Du meinst damit, dass in der RD-Decision SSIM anstatt SSE verwendet werden soll, wie aku im IRC vorgeschlagen hat? Ich kann mich mit der Idee irgendwie nicht anfreunden. Rein gefühlsmäßig. Und ausserdem wäre das vom Rechenaufwand her deutlich komplexer. Ob sich das lohnt?

    SSIM betrachtet Kontrast,Helligkeit und ein Skalarprodukt zwischen den auf Gesamthelligkeit 0 verdunkelten und auf Standardabweichung 1 skalierten Version von Referenz und Vergleichsblöcken.

    Zitat

    Noch ne prinzipielle Frage: Darf man in ASP jeden Block beliebig quantisieren oder gibt es nen maximalen Abstand zum frame quant?

    In XviD ist der größte mögliche Quantizer, der durch AQ erzeugt wird, das 1.5 Fache des Frame Quantizers, der kleinste der Frame Quantizer. Aber genaueres weiß ich nicht.

    Weiß jemand, wo man die Final Draft Version von MPEG4 ASP (oder irgendetwas ähnliches) herbekommt? Ich hätte da nämlich gern noch einige Fragen, bei denen so ein verbindliches Textwerk sehr nützlich wäre. Eine (kurze) Recherche meinerseits hat aber nichts ergeben.

    Ich hab jetzt mal einen ersten Versuchsballon in Sachen HVS RDO gestartet. Ist gar nicht mal so schwierig. Ich hab die Lambdas für die Farbinformationen geändert.
    Aber ich bin mir nicht ganz sicher, in welche Richtung ich die Lambdas ändern muss.

    Eine Verringerung des Lambdas für die Chroma Planes hatte größere Dateien bei konstantem Quantizer zu Folge.

    Eine leichte Erhöhung des Lambdas sorgte für eine kleinere Datei.

    Eine starke Erhöhung des Lambdas sorgte für sehr viel größere Dateien. (Das hängt aber vermutlich damit zusammen, dass aufgrund des Überschreitens von irgendwelchen Threshholds viel mehr Blöcke Intra gecodet wurden)

    Das verwirrt mich das irgendwie. Müsste es nicht andersherum sein?

    Es gibt eine Theorie, die besagt, dass das Universum sofort verschwinden und etwas noch Unerklärlicheres und Bizarres an seine Stelle treten wird, sobald jemand herausfindet, wofür es gut ist und warum es existiert.

    Es gibt eine andere Theorie, die besagt, dass das bereits geschehen ist.

  • Hallo Kopernikus,

    ich find's toll, dass sich jemand des berühmtesten 'vernachlässigten' Features von XviD annimmt! :)

    Allerdings muss ich zugeben, dass ich keinen wirklichen Unterschied zwischen Kodierungen mit neuem, 'normalem' AQ und altem, 'inversem' AQ erkennen kann. Dabei werden beim einen doch dunkle Flächen mit höherem als Base-Quantizer kodiert, beim anderen mit niedrigerem! Dunkel bleibt's aber in jedem Fall. :) Vielleicht liegt es daran, dass meine Augen sehr unsensibel für Details in dunklen Flächen sind (bin also ein ideales Opfer für 'psychovisuelle Trickserei'), vielleicht würde ich auch auf einer Flimmerkiste Blockbildung in dunklen Flächen erkennen können - auf dem TFT sehe ich jedenfalls eher keine Unterschiede.

    Das Problem ist, normales AQ spart 3-5% an Bitrate ein, inverses AQ setzt (scheint es) 20-25% an Bitrate zu. Wenn man sowie alles mit einem konstanten Quantizer komprimiert, ohne Platzprobleme fürchten zu müssen, ist das auch gut. Kann das Ergebnis von inversem AQ im 2-pass aber besser aussehen als das von normalem?

    Es werden anscheinend doch ordentlich Bits für dunkle Macroblocks verpulvert, welche im 2-pass-Szenario den Mitten fehlen könnten - also da wo man's wirklich sieht. Daher wäre es vielleicht ganz klug, eine Balance zwischen inversem und normalem AQ zu suchen, die annähernd +/- 0 kbps für Kodierungen mit oder ohne AQ anstrebt. Also entweder weniger inverse AQ oder zum Ausgleich stärkere normale AQ. Letzeres fände ich toll. Texture-masking, wie du es schon angesprochen hast, etwa. Ob das wohl in der Praxis ein Netto-Gewinn wäre?

    Aber ich wäre auch schon glücklich, wenn es erstmal nur ein gegen adverse Effekte wie Blöcke in einheitlich tiefblauen Flächen u. ä gepatchtes 'altes' AQ . gäbe - damit man jedem mit gutem Gewissen empfehlen könnte, AQ zu nutzen. Das wäre vielleicht doch noch was, das man in XviD 1.1 reinpacken könnte.

    Zur Wirkung von Lambda-Werten in XviD müsstest du noch was im englischen Forum finden können. Koepi hatte mal damit experimentiert und einen XviD-build veröffentlicht, der so deutlich höhere Kompression erreichte - nur gefiel der resultierende Detailverlust eigentlich niemandem. Auch hatte jemand mal DC-Koeffizienten-Modulation als Ersatz für AQ gebastelt; mit ähnlichem Ergebnis. Ich glaube, beides fand damals zur selben Zeit statt.

    Die Begrenzung der maximalen Abweichung des Block-Quantizers vom Base-Quantizer war, ebenso wie der Einbezug absoluter (und relativer, glaube ich mich zu erinnern) Helligkeit in die AQ-Entscheidung, ein Patch von sysKin, mit dem er das problemgeplagte AQ von heute auf morgen erst wirklich benutzbar machte. Es ist wohl in keinen Standards festgeschrieben, wie stark die Abweichung sein darf.

  • :welcome:

    freut mich, dass jemand den Thread wieder zum Leben erweckt.

    Zitat

    Allerdings muss ich zugeben, dass ich keinen wirklichen Unterschied zwischen Kodierungen mit neuem, 'normalem' AQ und altem, 'inversem' AQ erkennen kann. Dabei werden beim einen doch dunkle Flächen mit höherem als Base-Quantizer kodiert, beim anderen mit niedrigerem! Dunkel bleibt's aber in jedem Fall. Vielleicht liegt es daran, dass meine Augen sehr unsensibel für Details in dunklen Flächen sind (bin also ein ideales Opfer für 'psychovisuelle Trickserei'), vielleicht würde ich auch auf einer Flimmerkiste Blockbildung in dunklen Flächen erkennen können - auf dem TFT sehe ich jedenfalls eher keine Unterschiede.

    Ich hab auch nicht richtig krasse Unterschiede sehen können, aber ich hab hier auch nicht das richtige Equipment hier. Ausserdem hab ich nicht so richtig umfangreich getestet.

    Zitat

    Aber ich wäre auch schon glücklich, wenn es erstmal nur ein gegen adverse Effekte wie Blöcke in einheitlich tiefblauen Flächen u. ä gepatchtes 'altes' AQ . gäbe - damit man jedem mit gutem Gewissen empfehlen könnte, AQ zu nutzen. Das wäre vielleicht doch noch was, das man in XviD 1.1 reinpacken könnte.

    Das müsste recht einfach zu machen sein. So was ähnliches hat Haali ja für x264 gebastelt. Ich kann mal schauen, ob ich das demnächst hinkriege.

    Zitat


    Es werden anscheinend doch ordentlich Bits für dunkle Macroblocks verpulvert, welche im 2-pass-Szenario den Mitten fehlen könnten - also da wo man's wirklich sieht. Daher wäre es vielleicht ganz klug, eine Balance zwischen inversem und normalem AQ zu suchen, die annähernd +/- 0 kbps für Kodierungen mit oder ohne AQ anstrebt. Also entweder weniger inverse AQ oder zum Ausgleich stärkere normale AQ. Letzeres fände ich toll. Texture-masking, wie du es schon angesprochen hast, etwa. Ob das wohl in der Praxis ein Netto-Gewinn wäre?

    Irgendwo oben ist ein sehr plumper Versuch (mod1 oder mod2), "wilde" Blöcke mit viel Dynamik stärker zu quantisieren. Bei konstantem Quantizer liegen die resultierenden Dateigrößen in de Größenordnung wie beim offiziellen Lumimasking. Ich bin mir nicht ganz sicher, ob es mir gefällt. Teilweise gibt es Probleme in Blöcken, die zum Teil "Wild" und zum Teil "flach" sind.

    Wir können auch gerne versuchen, das alles irgendwie zu kombinieren. Es wäre mir nur recht, wenn etwas Feedback käme. Ich bin nicht so der XviD Experte und hab keine vom jahrelangen Encoden geschulten Adleraugen. ;D

    Es gibt eine Theorie, die besagt, dass das Universum sofort verschwinden und etwas noch Unerklärlicheres und Bizarres an seine Stelle treten wird, sobald jemand herausfindet, wofür es gut ist und warum es existiert.

    Es gibt eine andere Theorie, die besagt, dass das bereits geschehen ist.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!