x264 & AMD Prozessor

  • ok, also mein DualCore hatte 2x2,7GHz, mein Quad hat nun 4x2,3GHz.

    Und hier meine Fragen:

    wenn ich DirectShowSource() (und ich schätz auch mal bei DirectShowSource2()) nutze decodiert bei mit der ffdshow, wie kann ich da Defaults festlegen? gibts nen einfaches Tool (hab zB auch den CoreAVC drauf)?

    und gibts nen tutorial zu DGAVCIndex() und wie ich das dann via Avisynth als Input festlege? und da ich keine NVidia-Karte habe, bringts was? ich les da was von CUDA etc

    Danke mal wieder :)

    Gruß


  • ...Diese Aussage ist nun wirklich Blödsinn. Für die selbe Quell-Datei ist die Ausgabe aller H.264 Decoder immer identisch! Dafür gibt es schließlich Standards.


    So einen Blödsinn finde ich das gar nicht,
    ich bilde mir ein, dass ich bei unterschiedlichen Decodern auch Unterschiede sehe. :grübeln:

    Der nächste Beweis für mich ist ein CRC32 Vergleich von ein und demselben Frame. Ich habe ein Tool das Frames über einen CRC32 Vergleich wieder findet, das wiederfinden geht am schnellsten wenn auch der Hash Wert mit dem gleichen Decoder erstellt wurde. Bei CoreAVC funktioniert das ganze vorwärts sowie rückwärts am sichersten und schnellsten, auch bei nicht immer 100 % fehlerfreien Aufnahmen geht das fast fehlerfrei.

    CoreAVC und Cyberlink sind da in etwa vergleichbar, ffdshow und auch MainConcept versagen hier, bei Nero Decodern ist das teilweise ganz schlimm. Ein mit CoreAVC decodierter Frame lässt sich mit einem ffdshow oder MainConcept decodiertem Frame nicht immer über den Hash Wert vergleichen.
    Hier gibt es also doch Unterschiede, was mich aber auch nicht verwundert, nicht abschaltbare Filterungen, etc., dürften dafür verantwortlich sein.
    Wie sieht das der Fachmann?

    Deshalb auch meine Aussage dass ich CoreAVC am meisten vertraue, kein anderer von mir getesteter Codec lieferte fast zu 100 % immer den korrekten Frame und Hash Wert zurück.


    Im übrigen ist CoreAVC derzeit nicht dazu in der Lage, H.264 Streams mit Weighted P-Prediction korrekt zu dekodieren.


    Mit Weighted P-Prediction kenn ich mich nicht aus, bisher hat CoreAVC alles decodiert was ich Ihm angeboten habe. ;)

    Nachtrag:
    Fire such mal nach DirectShow FilterManager, damit lässt sich der bevorzugte Decoder auswählen,
    oder mit GraphEdit eine GraphDatei mit den gewünschten Decodern erstellen, und diese dann mit Avisynth öffnen.

    Gruß gispos

    4 Mal editiert, zuletzt von gispos (15. Dezember 2009 um 21:53) aus folgendem Grund: Nachtrag

  • und gibts nen tutorial zu DGAVCIndex() und wie ich das dann via Avisynth als Input festlege?

    Das halbe Forum. Einfach mal die Suche benutzen und lesen. Und außerdem die beigelegte Dokumentation (allerdings englisch).

    und da ich keine NVidia-Karte habe, bringts was? ich les da was von CUDA etc

    Da gibt es einen kleinen Unterschied zwischen DGAVCDec und DGAVCDecNV.

  • Das Encodieren sollte bei gleichen Einstellungen mit der neuen CPU etwas schneller sein, in Taskmanager mal die CPU-Auslastung kontrollieren.
    Die Einstellungen sollte man unter ffdshow >Videodekoder-Konfiguration > Codec ändern können.

    LoRd_MuldeR
    Was Dark Shikari da schreibt klingt irgendwie einleuchtend, aber ich vermute die Unterschiede sind gering.
    Ich meine auch bei kleineren Änderungen aber das könnte das encodieren schon merklich beschleunigen ohne die Qualität zu sehr zu beeinträchtigen.

  • Hey

    danke für die ganzen Infos, komm fast nimma hinterher :P der ShowFilter Manager funktioniert, danke!!!

    also da meine Quelle eine BluRay und somit ein VC-1 ist kommt nur der MS-Decoder und ffdshow in frage, CoreAVC, DivXHD etc können das wohl net :(

    ach ja, und DGAVCDec scheint ja nicht mehr entwickelt zu werden, und auf der Entwickler HP kann mans auch nimma runterladen, muss ich morgen mal ne Quelle suchen. Und DirectShowSource2() scheints auch nicht zu geben? War das ein Tipfehler oder hast du ein Plugin welches das ermöglicht? :)

    Bis morgen, gut nacht

    MFG

  • So einen Blödsinn finde ich das gar nicht,
    ich bilde mir ein, dass ich bei unterschiedlichen Decodern auch Unterschiede sehe. :grübeln:

    Der nächste Beweis für mich ist ein CRC32 Vergleich von ein und demselben Frame. Ich habe ein Tool das Frames über einen CRC32 Vergleich wieder findet, das wiederfinden geht am schnellsten wenn auch der Hash Wert mit dem gleichen Decoder erstellt wurde. Bei CoreAVC funktioniert das ganze vorwärts sowie rückwärts am sichersten und schnellsten, auch bei nicht immer 100 % fehlerfreien Aufnahmen geht das fast fehlerfrei.

    CoreAVC und Cyberlink sind da in etwa vergleichbar, ffdshow und auch MainConcept versagen hier, bei Nero Decodern ist das teilweise ganz schlimm. Ein mit CoreAVC decodierter Frame lässt sich mit einem ffdshow oder MainConcept decodiertem Frame nicht immer über den Hash Wert vergleichen.
    Hier gibt es also doch Unterschiede, was mich aber auch nicht verwundert, nicht abschaltbare Filterungen, etc., dürften dafür verantwortlich sein.
    Wie sieht das der Fachmann?

    Deshalb auch meine Aussage dass ich CoreAVC am meisten vertraue, kein anderer von mir getesteter Codec lieferte fast zu 100 % immer den korrekten Frame und Hash Wert zurück.

    Um es nochmal klar zu machen: Es gibt nur genau eine Möglichkeit einen gültigen H.264 Bistream korrekt zu dekodieren. Es gibt da keinen Spielraum! Würde jeder Decoder ein eigenes Süppchen kochen, bräuchten wir auch keine Standards. Als Encoder muss ich mich darauf verlassen können, dass jeder Decoder meinen Bitstream später so interpretieren wird, wie es im Standard vorgesehen ist. Ansonsten wäre der H.264 Encoder von Firma X auch nur mit dem Decoder von Firma X kompatibel, aber nicht mit dem von Firma Y oder Firma Z. Sowas wäre dann ein proprietäres Format und kein offizieller ISO/MPEG/ITU Standard. Auch das Deblocking ist bei H.264 ein fester Bestandteil des Encodierungs- bzw. Decodierungsvorgangs und eben nicht optional. P- und B-Frames referenzieren auf die bereits deblockten Referenz-Frames, d.h. wenn man das Überspringen des Deblockings erzwingt (manchmal als "Speed-up Trick" angeboten), kann der Stream nicht korrekt dekodiert werden und deutliche Artefakte sind vorprogrammiert.

    Warum du beim Dekodieren des selben Streams verschiedene Hash-Werte erhältst, kann ich dir nicht sagen. Möglicherweise geht beim Vergleich irgendetwas schief. Zum Beispielen können die Dateien, die du vergleichst, unterschiedliche Meta-Daten (wie z.B. Timestamps) enthalten, welche in die Berechnung eingehen. Man muss also darauf achten, dass man die Hashes tatsächlich ausschließlich über die Pixel-Daten und über nichts anderes berechnet! Möglicherweise ist aber auch dein H.264 Stream einfach nicht 100% korrekt. Dann kommt Fehler-Korrektur ins Spiel, was natürlich von jedem Decoder anders gehandhabt werden kann (z.B. teilweise dekodierten Frame trotzdem ausgeben -vs- letzten korrekten Frame nochmal anzeigen). Und natürlich kann es auch sein, dass einer der Decoder doch irgendwo einen minimalen Fehler macht. Wir wir all wissen, führt bereits ein einziges falsch dekodiertes Pixel (was in der Praxis vollkommen irrelevant da nicht wahrnehmbar wäre) zu einem komplett anderen Hash-Wert.

    Wenn man es ganz genau wissen wollte, müsste man den H.264 Referenz-Decoder zum Vergleich heranziehen:
    http://iphome.hhi.de/suehring/tml/

    LoRd_MuldeR
    Was Dark Shikari da schreibt klingt irgendwie einleuchtend, aber ich vermute die Unterschiede sind gering.
    Ich meine auch bei kleineren Änderungen aber das könnte das encodieren schon merklich beschleunigen ohne die Qualität zu sehr zu beeinträchtigen.

    Natürlich kann man "schnellere" Encoder-Settings durch eine höhere Bitrate kompensieren. Aber man muss sich bewusst sein, dass CRF keine perfekt konstante Qualität liefert, sondern eben auch von den verwendeten Encoder-Settings abhängt. Wenn man also plötzlich deutlich "schnellere" Settings verwendet, muss man also eventuell auch den CRF Wert nachjustieren...

  • Ja ich vergleiche die reinen Pixel, und klar ist auch, dass bei nur einem Pixel Abweichung ein anderer Hash Wert herauskommt.

    Ist aber auch egal, ob nun durch interne Filterungen, Fehlerbehandlungen oder was auch immer, es gibt messbare sowie Visuell sichtbare Unterschiede beim decodieren von ein und demselben Video Stream.

    Noch kann ich meinen Augen trauen. :D

    Das Ganze erinnert mich ein wenig an Digitale Musik, da gibt es auch genügend Standards…
    Gruß gispos

  • Hier mal 2 Bilder zum vergleichen, eines vom CoreAVC das andere vom Cyberlink 9.
    DXVA wurde deaktiviert, alle Einstellungen auf 0.
    Der Frame Puffer wurde direkt in das Bitmap kopiert, es wurde nichts nachbearbeitet.
    Im Archiv befinden sich die Original Bitmaps.

    Cyberlink
    [Blockierte Grafik: http://img686.imageshack.us/i/cyberlinkd.j…berlinkd.th.jpg]http://img686.imageshack.us/i/cyberlinkd.jpg/
    [Blockierte Grafik: http://img686.imageshack.us/i/cyberlinkd.j…berlinkd.th.jpg]

    CoreAVC
    http://img52.imageshack.us/i/coreavc.jpg/


    [Blockierte Grafik: http://img52.imageshack.us/i/coreavc.jpg/…290/coreavc.jpg]

  • Du hast recht.
    Kann den CoreAVC so einstellen dass das Ergebnis dem CyberLink oder DivX-H246 gleicht. CoreAVC bietet zumindest den Vorteil die richtigen Einstellungen automatisch vorzunehmen, beim Cyberlink oder DivX-H264 gibt es keine Möglichkeit die Werte zu ändern.

    Danke für den Link, wieder etwas Bildung mehr.

    An der guten Dekodierung, auch bei nicht perfektem Quellmaterial, lass ich aber nicht rütteln. :)

  • Wenn man zum Dekodieren ffdshow benutzt kann man das Bild aber noch etwas verbessern :)
    BeiVideodekoder-Konfiguration moderate Einstellungen beim Schärfen, Rauschen und unter Größe und Seitenverhältnis die Auflösung des Monitors bei Horizontale Größe angeben, selbst "zermatschtes" material wird so noch etwas ansehnlicher :)

Jetzt mitmachen!

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