Beiträge von Teegedeck

  • XviD Lumimasking

    Huihuihuihuihui, beeeee-eindruckend!

    Voran, Didée, voran; ich erwarte mir innerhalb der nächsten zwei Tag ein auf die SixOfNine-Matrix abgestimmtes Profil! Auf meinen Schreibtisch! ;)

    Ernsthaft, das ist wirklich eine super-duper Leistung, Kopernikus! Vielen Dank! Mal sehen, ob auch ich damit herummurksen kann.

  • UU-Codierung?

    Oha, da fühl' ich mich an alte Zeiten erinnert: UUE-Kodierung war damals notwendig, um Anhänge in Newsforen zu posten (genau wie MIME für Mails). Wandelte alles in Zeichensalat um, den der Leser anschließend aus einem Newsbeitrag rauskopieren, in ein leeres Textdokument einsetzen und dann wieder in das Attachment umwandeln konnte. Mutete damals an wie Zauberei. Heutzutage machen das die Clients von selbst, ohne dass man's merkt.
    http://de.wikipedia.org/wiki/UUencode

  • XviD 1.x - aktuelle Version

    Das mit der verschlechterten Qualität hat sysKin umgehend zurückgenommen. Jetzt ist im Gegenteil die Rede von leicht besserer Qualität (bei Kodierung in zwei Durchgängen). Bei konstantem Quantizer werden jedoch höhere Bitraten produziert (nur ohne VHQ, glaube ich) und die Verlangsamung ist tatsächlich vorhanden. Also erstmal ein lautes "Entwarnung!".

  • XviD Lumimasking

    Heyyyyy, Didée; nice talking to you in Tschörmän... ;D

    Zitat von Didée

    Teegedeck: Also, bei mir waren's nur ca 15% mehr.

    Joup, wenn ich nun eine Größenvoraussage über einen kompletten Film mit Enc mache, statt Testclips zu kodieren, sehe ich das auch. Und viel hängt wohl auch vom Grad der Quantisierung ab; hier einige Werte:
    SixOfNine@2: 100%
    SixOfNine@2 + AQ: 154,5%

    SixOfNine@4: 100%
    SixOfNine@4 + AQ: 115,6%

    H263@6: 100%
    H263@6 + AQ: 107,5%

    Daraus könnte man erstmal den Schluss ziehen, dass man das neue AQ für quant=2 verbieten sollte. Quantizer 2 sieht ohnehin gleichmäßig gut aus und quant=1 ist einfach schierer Wahnsinn.

    Zum andern sieht man klar, dass neue, 'positive' AQ um so weniger kostet, je stärker komprimiert wird. Ist der logische Schluss, dass man alte, 'negative' AQ bei niedriger Kompression forcieren sollte (etwa: maximaler Unterschied zum Base Quantizer darf = 3 oder 2 sein), um die positive auszugleichen, und sie dann mit steigendem Quantizer nach und nach zurücknehmen sollte? Oder dass man umgekehrt positive AQ bei quant= 3 kaum und dann immer stärker einsetzen sollte, je höher quantisiert wird?
    [edit]Da muss man wohl einfach austesten, was besser ist.[/edit] Der XviD-typische Ausweg wäre wohl ein benutzerdefinierbarer Wert 'AQ-Stärke'... Hurk!

    Zitat von Didée


    Trotzdem, Du hast recht: sehr viel Unterschied sieht man z.Zt. nicht. Es ist durchaus einer da, aber ... ein guter Teil der optischen Verbesserung wird durch die B-Frames verschleiert. Die laufen ja mit "normalem" Quantizer weiter (kein AQ für B's), und können nur durch die "bessere" Referenzierung nicht in dem Maße bessere Ergebnisse liefern, wie die P-Frames mehr Bitrate ziehen. Zumal in dunklen Szenen B-Frames typischerweise sehr zahlreich anzutreffen sind ...

    A-haaa!

    Zitat von Didée

    Bekräftigen möchte ich allerdings mein Veto gegen AQ-für-detailreiche-Blöcke, und auch gegen Texture Masking. Ersteres schon allein vom theoretischen Ansatz her - Detail ist das, was der Codec so verzweifelt zu transportieren versucht. Wollen wir das wirklich stärker quantisieren? Ich nicht. Und wenn man's nur auf extrem hochfrequentes Detail beschränkt (d.h. auf mögliches "Salt-and-Pepper"-Pixelrauschen), dann ... kann man gleich eine Q.matrix verwenden, die die höheren Frequenzen stärker 'rannimmt ;)
    Und, Texture Masking: in dem zuvor geposteten Screenshot sieht das ja wunderbar aus: man sieht es nicht. Man sieht es in dem Screenshot nicht. Sobald aber eine Folge von Bildern abläuft, würde man sehr wahrscheinlich ein höchst lästiges Flimmern wahrnehmen, wo eigentlich eine "stabile" Textur sein sollte. Eine Textur mit gleich aussehendem "Schrott" zu ersetzen funktioniert nicht, weil der "Schrott" nicht über die temporale Achse stabil bleibt, sondern zufällig ist.

    Agreed. ;) Gäbe es einen Weg, 'künstlichen Schrott' zu stabilisieren; skip-blocks o.ä.? Oder wären 'Lambdaleien' ('Herumfummeln am Lambda':)) der richtige Weg?

  • XviD Lumimasking

    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.

  • Mkv Container in Avi Container... Dropped Frames?

    Ja, scheint wirklich ein tolles Urlaubsvideo zu sein. :)

    Am besten: mkvtoolnix runterladen, dazu das mkvextract-GUI (setzt allerdings ein installiertes .NET voraus) und damit bequemer extrahieren als mit der Kommandozeile.

    Übrigens, man kann für MKVs mit Haalis tollem Mediasplitter alles einstellen, was nur denkbar ist: Z.B. die Präferenzen für Tonspuren und Untertitel!! Du kannst z.B. angeben, dass du - so vorhanden - immer eine englische Tonspur hören und dazu russische Untertitel lesen willst; und wenn's keine russischen gibt, dann eben niederländische - oder was auch immer. ;)

    Neu kodieren ist nur zeitraubend, qualitätsmindernd und überflüssig.