beste qualität?

    Hallo,

    Als Neuling bin ich von eurem Forum echt beeindruckt, und ich hoffe das ihr mit auch helfen könnt.

    Nun zu meinem anliegen.

    Ich encode schon seid einer weile mit einem 1st pass vom 2-pass mode als Ergebniss. Die Einstelungen sind: minquant 2, MS 6, VHQ 4, chromamotion, manchmal cartoonmode, kein Qpel,kein GMC,kein AQ der rest alles def. packed bitstream hab ich an. Es kann sein das es kein Sinn macht aber erstmal weiter.
    Nun die Frage: gibt es vieleicht noch eine Möglichkeit genaus so eine sehr gute Qualität zu erreichen aber mit besserm speed/ geringerer Größe? Die Filegröße ist bei mit 30min/500MB/720x576xYUV2 und bin damit sehr zufrieden.
    Wie gesagt sollte die End-Qualität kaum vom SRC zu unterscheiden sein.
    Ausserdem ist es qualitäts mässig schlechter keinen x/y wert mit Teiler 16 zu haben? Wenn ja, ist es besser lieber dann einen Schwarzenrand zu lassen ( mit blick auf die Filegröße).
    Ausserdem wenn ich nur den 1st-pass verwende welche Einstellungen kann ich weglassen, die ja sowieso nur im 2nd-pass verwendet werden?

    und wie kann ich es dem Decoder leichter machen zu decodieren?

    ich hoffe ich hab euch nicht gleich erschlagen , und ihr könnt mir helfen. :D

    :welcome:

    Viele schwierige Fragen...

    Wenn du trotz guter Optionswahl kleinere Fateien bei Top-Qualität haben willst, dann dürfte dir wohl nur noch übrig bleiben, mit dem Matrizen zu experimentieren: H.263 wird oft kleiner, aber weicher als MPEG, und über eigene Matrizen ist noch schwerer etwas allgemeingültig zu sagen...

    Wenn dir VHQ=4 zu langsam ist, dann nimm da ruhig auch kleinere Stufen, aber mindestens 1.

    Die wichtigsten Sachen, die beim 1st-pass vernachlässigbar sind, schaltet XviD schon freiwillig ab. Du solltest dir vor allem überlegen, wie stark eine Option Bildinhalt und Komprimierbarkeit beeinflussen kann, wenn du erwägst, sie beim 1st-pass zu deaktivieren - empfehlen würde ich dir Unterschiede grundsätzlich nicht, außer vielleicht bei VHQ (1 genügt bei 1st-pass mit Sicherheit).

    Die Teilbarkeit durch 16 ist normalerweise sinnvoll, damit keine Kanten durch Makroblöcke hindurchlaufen - in dem Fall würden sie für eine gute Rekonstruktion viel Bitrate verschwenden. Also möglichst keine schwarzen Ränder im Bild lassen, lieber etwas stärker resizen und eine leichte Verzerrung riskieren. GordianKnot & Co. helfen einem normalerweise dabei recht gut.

    Schneller decodieren ist möglich, indem man Postprocessing-Optionen im Decoder ausschaltet. Ich denke, das Nicht-Verwenden von QPel kann auch ein wenig helfen; ansonsten dürfte es wohl wenige Optionen geben, die die Komplexität der codierten Daten erheblich beeinflussen; der Großteil der Decodierung ist sicherlich kaum veränderlich, denke ich.

    Danke erstmal!

    ich hab da noch eine frage speziell wegen dem Teiler 16... wenn ich das richtig verstanden habe : also wenn man ihn nicht hat verschwendet man nur bytes aber einfluss auf die qualität hat es nicht?
    wegen dem VHQ kann man den nicht voll abschalten? weil die infos doch nur im second pass genutzt werden oder?
    Da stellt sich nun die frage was der first pass nun wirklich macht oder eher was er als video output ausgibt. ich dachte,das vorallem die quantization die komprimierung im ersten durchlauf ausmacht, und die weiteren optionen eher im 2 durchlauf genutzt werden?!

    LigH:
    also wenn du meinst man soll keine schwarzen ränder lassen u stattdessen etwas mehr resizen, heisst das dann, das der wert auf der x/y - Achse durch 16 teilbar sein soll?
    also 16 - 32 - 48 usw.?
    was geschieht wenn GK beim autocroppen auf 0 croppt? soll man trotzdem auf 16 gehn?

    wie schauts mit der zahl 4 aus? hab mal irgendwo vernommen das wenn man croppt eine durch 4 teilbare zahl nehmen soll? stimm das? oder soll ich bei XVID trotzdem eher zu 16 tendieren?

    z80: Warum verwendest du nicht einfach 1Pass Quality mit Quantiser 2. Das sollte besser und evtl. auch schneller sein.

    Zitat aus Selurs "Wissenswertes rund um XviD":

    Zitat


    Während des 1st pass wird, wie bereits erwähnt, einiges an Daten gesammelt. Was ich aber vorher bewusst verschwiegen habe, ist, dass dabei nebenbei auch ein Videostream erzeugt wird. Deaktiviert man diese Option, so wird dieser nicht mehr standardmäßig gelöscht, sondern bleibt erhalten. Da der so erstellte Videostream aber eventuell nicht mehr Mpeg4 Standardkonform ist rate ich davon ab dieses Feature zu deaktivieren.


    zum Croppen:
    Mit einer durch 16 teilbaren auflösung seid ihr auf jeden Fall auf der sicheren Seite.

    Warum die Auflösung durch 4 Teilbar sein soll, kann ich mir nicht erklären. 8 Pixel ist die größe eines Luminanz Makroblocks, 16 Pixel die Größe eines Chrominanz Makroblocks.

    Falls der schwarze Balken durch einen Makroblock geht, könnte das Moskitos am Rand hervorrufen bzw. den Bitratenbedarf erhöhen, ich würde eher ein paar Pixel vom Bild abschneiden.

    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.

    Es gab Grafikkarten (besonders Matrix Millennium G4xx), die nicht in der Lage waren, Videos mit nicht durch 16 oder gar 32 teilbaren Größen (v.a. Breite) schnell per Overlay darzustellen, statt dessen wurde dafür langsameres Blitting (programmgesteuertes Kopieren von Bitmaps in den Grafikspeicher) verwendet. Als Work-Around hatte man damals den DivXG400-Filter entwickelt, der das Videobild auf Größen aufweitete, die durch 16 teilbar sind, indem er schwarze Ränder drum herum setzte.

    In den üblichen Konvertierungstools (wie GordianKnot, AutoGK, DVX, FlasK/Xmpeg usw.) wird üblicherweise das Video so vorbereitet, dass man zunächst alle schwarzen Ränder um das Video herum abschneidet, so dass die äußersten Pixel des Ausschnittes sicher interessanten Bildinhalt enthalten, und es anschließend so verkleinert, dass die Größen durch 16 teilbar werden - das geht natürlich nicht immer so, dass Höhe und Breite ganz exakt mit dem selben Verhältnis verkleinert werden, aber die Programme achten automatisch darauf, dass es mit möglichst geringer Abweichung passiert, und zeigen die Abweichung (Aspect Ratio Error) auch an.

    Außer für Stand-Alone-Player, die zu blöd dazu sind, ordentlich wieder zurück auf Vollbild zu vergrößern, würde ich es eigentlich niemals empfehlen, DivX/XviD-Videos ohne Croppen und Resizen zu erzeugen (ganz besonders nicht bei anamorphem Video, klar...). Manche wollen sicherlich vermeiden, durch die Größenänderung an Schärfe und Details zu verlieren; mir wäre es dagegen wichtiger, keine überflüssigen schwarzen Ränder im Bild zu haben, die Bitrate verschwenden, indem ihre Kanten zum interessanten Bildinhalt mitten durch Makroblöcke laufen.

    FitCD erzeugt übrigens absichtlich (für Video-CDs) Bildmaterial, das zwar schwarze Ränder enthält (wegen "Overscan"), achtet aber darauf, dass diese Ränder durch 16 teilbare Größen haben, damit sie exakt über einzelnen Makroblöcken liegen, und Bitratenverschwendung vermeiden.

    Hier ein altes Statement von LigH was ich mal im FlaskmpegBoard in die FAQs gepackt hatte:

    Zitat

    02) Warum sollte die Auflösung durch 16teilbar sein? by Ligh
    Einerseits ist die Decodierung von MPEG besonders schnell, wenn die Bildgröße sowohl horizontal als auch vertikal je durch 16 teilbar ist, weil die Farbdifferenz- Informationen (U/V- bzw. Cb/Cr-Komponenten) die halbe Auflösung haben und die DCT-Blöcke also doppelt so groß sind wie die Helligkeits-DCT-Blöcke (Y-Komponente), die 8x8 Pixel groß sind.

    Andererseits ist auch eine Teilbarkeit durch 32 in der Waagerechten sinnvoll, weil viele Grafikkarten so breite Blöcke schneller von einem Bereich des Videospeichers zum anderen kopieren können.

    Ergänzt seine Äußerung nochmal :)

    Cu Selur

    Wie berechnen denn nun Xvid bzw. DivX die DCT wenn ich ein nicht durch 16 teilbares Video ohne schwarze Ränder vorlege? Legen sie sich dummy Ränder? Wo fangen sie dabei an zu zählen? Wenn sie irgendwo am Rand anfangen, hätte ich ja nur zwei Kanten.:cool:

    Viele Grüße bb empty

    Die Codecs erweitern das Bild dann intern auf die nächst größere Fläche, deren Dimensionen durch 16 teilbar sind. Welchen Inhalt dabei die Flächenerweiterung hat, kann ich nicht genau sagen; es gibt aber sicher bessere Möglichkeiten, als einfach bloß schwarz - zum Beispiel gespiegelter Inhalt der Umgebung: Das macht nicht so große Probleme mit dem Bitratenbedarf an Kanten.

    Bei der Darstellung wird entsprechend wieder alles abgeschnitten, was über der gespeicherten Auflösung liegt.

    Zitat von LigH

    @ Selur:

    Wer kann schon C lesen? Für einige sind doch schon deutsche Dokumentationen zu schwer! ;)


    grins .... und ich möchte nicht wissen wieviel Programmierer es gibt die sich in ihrem Fach bestens auskennen aber zu doof sind ein Diktat ohne massenweise Fehler zu schreiben. ;)

    bye, Calderon

    Leider kann ich weder C noch C++ lesen, aber Rechtschreibung habe ich einigermassen drauf.:D Trotzdem danke für die Erklärung. Allerdings hört es sich für mich nicht so "schlimm" an, wenn man nicht mod16 croppt. Aber vielleicht mache ich ja mal ein paar Vergleichstests.:)
    Viele Grüße bb empty

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden