x264 bester Videocodec?

  • In der Chip-Ausgabe 10/2012 hat im Test der x264-Codec besser abgeschnitten als jede Kaufsoftware. In einer Grafik wird zum Vergleich der 800€ teure Mainconcept Totalcode herangezogen, der jedoch nicht den SSIM-Wert des x264 erreicht. Mit x264 codierte Videos "sehen optisch einfach besser aus", schreibt die Zeitschrift.

  • Zitat

    In der Chip-Ausgabe 10/2012 hat im Test der x264-Codec besser abgeschnitten


    das bezweifelt hier auch niemand dass der freie x264 erste Wahl ist.

    Andrerseits hat Chip früher ganz gross danebengehauen bei den damaligen S-VHS Rekordervergleiche.
    Bei denen kamen die beiden Pana`s NV-SV121 und der NV HS930 auf die ersten Plätze.
    Die haben keine Ahnung.

    Angaben/Bewertungen in der Zeitschrift c`t von Volker Zota würde ich im Gegensatz zu denen von Chip und Co eher vertrauen.

    MainConcept gehört nun ja wirklich nicht zum obersten Standard.

    Datenrettungen Normwandlungen Restaurierungen Digitalisierungen

  • Zitat

    MainConcept gehört nun ja wirklich nicht zum obersten Standard.


    Naja, finde den H.264 Codec von denen schon ziemlich gut, hat auch bis jetzt bei den jährlichen MSU MPEG-4 AVC/H.264 Video Codec Vergleichen immer ganz gut abgeschnitten,...
    Wer gehört den Deiner Ansicht nach sonst aktuell zur Oberliga wenn es um H.264 geht?

  • Ich meine das eher als Ganzes,also als Paket MC Reference...gehört nicht zum "obersten Standard"
    Obersten Standard ist der Broadcastbereich.
    Hätte vielleicht etwas differenzieren sollen,den besagten Codec bekommt man ja nicht "lose" sondern nur als "Plugin" zu Reference.
    Reference beinhaltet wenn ichs noch recht weiss in der Grundbasis nur den mpeg2 Enc.und der war damals weit hinter der Quali vom Procoder und dem kostenlosen HCEnc.

    Adobe und auch Pinnacle greifen auf diesen x264 zu von MainConcept.

    Nachtrag.
    Tatsächlich,der x264 von Mainconcept ist bei allen 4 Streams jeweils immer auf dem 2 Platz.

    Seite 9 +24 in dieser PDF
    http://compression.ru/video/codec_co…_comparison.pdf

    Hätte da eher den Elecard gesehen.

    Jetzt im Nachhinein fällts mir wieder ein wo ich eine schlechte Quali bekommen habe mit dem MC x264.Das war bei einem Test mit der Software Pinnacle HD 15 Ultimate,das Tool arbeitet intern in RGB,ein paar Aenderungen/Filter....Ausgabe mp4...
    Seither liegt die Soft säuberlich verpackt wieder im Originalkarton und wird keines Blickes mehr gewürdigt.

    Datenrettungen Normwandlungen Restaurierungen Digitalisierungen

    4 Mal editiert, zuletzt von Goldwingfahrer (7. September 2012 um 19:35)

  • 1) x264 ist aber überhaupt nicht von MainConcept, sondern vom VideoLAN-Team. Der Encoder von MainConcept heißt nicht x264, sondern z.B. "MPEG Pro™ HD".

    2) Keine technische Metrik bildet bisher menschliche Empfindungen zuverlässig ab. So hat x264 beispielsweise psychovisuelle Verbesserungen, die den SSIM-Wert verschlechtern würden, obwohl sie ein angenehmer wirkendes Ergebnis erzeugen können.

    3) Es gibt bereits einen H.265-Encoder (HEVC), der ein noch besseres Verhältnis zwischen Bildqualität und Platzbedarf haben soll. Aber er rechnet auch mit modernen Prozessoren noch im Bereich von Sekunden bis Minuten pro Bild, ist daher also noch längst nicht praxistauglich.

  • Zitat

    Der Encoder von MainConcept heißt nicht x264, sondern z.B. "MPEG Pro™ HD".

    Ja,"x264" nennt sich das Teil nicht,das wäre die "praktische" Implementierung als Software,sondern genauer H.264/AVC
    das ist wiederum wie Du schon mehrmals beschrieben hast die "Video Komprimierungsart"

    New features in Codec SDK include an H.264/AVC encoder wrapper (available separately) -
    gelesen hier
    http://www.mainconcept.com/products/sdks/video/h264avc.html

    Zitat


    1) x264 ist aber überhaupt nicht von MainConcept,


    das wird so sein wie Du es schreibst,wusste ich nicht........ist genauso wie wenn man ein Auto oder sonst eine Maschine kauft...wer der Teile-Zulieferer ist interressiert den Endkäufer herzlich wenig.

    Nachtrag:
    Screen aus MC Reference-Demo Version.
    Mpeg-4 HD wird separat aufgelistet.
    http://frupic.frubar.net/shots/27026.png

    Datenrettungen Normwandlungen Restaurierungen Digitalisierungen

    Einmal editiert, zuletzt von Goldwingfahrer (8. September 2012 um 14:11)

  • Auch HEVC ist noch nicht das Ende der Fahnenstange. Nach der Frage¹, ob denn noch eine weitere Eigenentwicklung nötig sei, schließlich hätten wir heute schon den On2/Google VP9, antwortete schweinsz²:

    ¹

    Zitat von hajj_3

    We already have VP9 now though, i don't see much point in your codec being created as google's codec is going to be great and will have hardware decoding built into chips.

    ²

    Zitat von schweinsz

    Do you mean that a new codec is useless? I can do better than VP9, perhaps better than HEVC.

    Da hat er sich ja eine Herausforderung gestellt. :eek:

  • zu schweinsz: Wenn er da wie bei seinem H.264 Decoder, ohne Versionsverwaltung und im gewohntem Spaghetti-Code alleine an dem Teil schreibt, wäre es schon fast ärgerlich, wenn er mit vp9&co konkurrieren könnte. (da Updates, Fixes, Erweiterungen wohl, wie bei ihm gewohnt, auch bei kleinen Sachen sehr lange dauern würden)

  • zu schweinsz: Wenn er da wie bei seinem H.264 Decoder, ohne Versionsverwaltung und im gewohntem Spaghetti-Code alleine an dem Teil schreibt, wäre es schon fast ärgerlich, wenn er mit vp9&co konkurrieren könnte. (da Updates, Fixes, Erweiterungen wohl, wie bei ihm gewohnt, auch bei kleinen Sachen sehr lange dauern würden)

    Lass ihn machen ... man wird sehen, was rauskommt.

    Wird interessant werden, welcher Codec/Codecfamilie das Rennen machen wird.

    mfg
    monarc

  • Zitat

    Wird interessant werden, welcher Codec/Codecfamilie das Rennen machen wird.


    Anfangs vermutlich HEVC, weil da mehr Leute dran arbeiten und unterschiedliche Firmen eigene En- und Decoder herausbringen werden, so dass zu hoffen ist, da man da bald einen von der Geschwindigkeit brauchbaren Encoder hat.
    Wenn dann VP9 optimiert genug ist, dass es von der Geschwindigkeit mit dem dann aktuellen Encodern einigermaßen mithalten kann (es eine offizielle mkvtoolnix Version gibt die VP9 unterstützt) werden sich wohl auch einige Leute mehr mit VP9 beschäftigen.
    -> momentan ist das noch alles sehr uninteressant für fast alle Anwender.

    Davon ausgegangen, dass VP9 und HEVC vergleichbare Qualität liefern sollten, würde die Decodinggeschwindigkeit interessant werden.
    (Die meisten Tablets, Phone&Co sind ja eher etwas schwachbrüstig und bis die ersten brauchbaren Hardwaredecoder kommen wird es wohl noch dauern und diese wären dann auch nur für neue Geräte interessant.)

    Cu Selur

  • Anfangs vermutlich HEVC, weil da mehr Leute dran arbeiten und unterschiedliche Firmen eigene En- und Decoder herausbringen werden, so dass zu hoffen ist, da man da bald einen von der Geschwindigkeit brauchbaren Encoder hat.


    Für welchen Verwendungszweck haben sie HEVC denn vorgesehen?

    TV Streams / Bluray (auch wohl 4k) werden - ähnlich wie damals beim Übergang MPEG2 -> MPEG4-ASP - vielleicht einen Codec überspringen und bei H.264 bleiben. Einige Ami Sender kodieren ja sogar HD Streams noch mit MPEG2.
    Große Video-on-Demand-Streamer (ala Netflix) kenne ich eher aus den USA, also nur dort von Bedeutung. Bei uns ist das ja eher klein.
    Youtube ist VP9-Welt ... wenn Google schon einen eigenen Codec macht, werden sie ihn auch irgendwann einsetzen und nicht unbedingt HEVC verwenden.



    Wenn dann VP9 optimiert genug ist, dass es von der Geschwindigkeit mit dem dann aktuellen Encodern einigermaßen mithalten kann (es eine offizielle mkvtoolnix Version gibt die VP9 unterstützt) werden sich wohl auch einige Leute mehr mit VP9 beschäftigen.
    -> momentan ist das noch alles sehr uninteressant für fast alle Anwender.


    Ob VP9 der große Wurf wird, hab ich so meine Zweifel. Aber man wird sehen.

    Mir gefällt aber, dass der Sourcecode verfügbar ist und so auf jeden System nutzbar ist.
    Auch ist Google flexibler. H.264 ist jetzt 10 Jahre alt und sollte der Nachfolger von HEVC wieder 10 Jahre brauchen, hat Google sehr viel Zeit.
    Optimierungen dauern lange, aber irgendwann holt man halt nur noch wenig raus. Google wird sicher nicht 10 Jahre VP9 optimieren, wenn man mit einem VP10/11/12 großere Fortschritte machen kann.
    Und bei HVEC vs. VP10 ... wer weiß, wie es dann aussehen wird.

    mfg
    monarc


  • Davon ausgegangen, dass VP9 und HEVC vergleichbare Qualität liefern sollten, würde die Decodinggeschwindigkeit interessant werden.

    Mal ein wenig gespielt und mir eine 52 sek VP9/Opus MKV Datei erstellt (sintel Trailer). Spielt auch brav - nach einer kleinen Änderung- in mpv (mplayer-fork) ab.

    Bei dem Kurztest (jeweils 2Pass, Bitrate 1000, bei x264 Preset Placebo) gefällt mir die VP9 Quali ganz gut, auch wenn man da noch wenig vergleichen kann.
    -> X264 Preset Placebo gegen zufällig in einem Mailinglisten Thread gefundene Einstellungen für VP9.

    Der Encoder ist sehr langsam. Hoffentlich noch nicht optimiert und single threaded.
    Auch kurz mit mpv die Decoder grob verglichen.

    Durch den 52sek-Videostream decodiert er sich auf meinem 4Kern-i5 bei:

    H264 in ca. 2.027s (ffmpeg Decoder, hoch optimiert und multi threaded)
    VP9 in ca. 12.605s (libvpx Decoder, vermutlich wenig optimiert und single threaded)

    wenn ich auch den H264 Decoder auf single threaded runterschalte, erhalte ich:

    H264 in ca. 9.302s (ffmpeg Decoder, single threaded)
    VP9 in ca. 12.458s (libvpx Decoder, vermutlich single threaded)

    Beide Streams bringen meinem i5 in keinster Weise ins Schwitzen beim Decodieren.

    mfg,
    monarc

  • Es kommt Bewegung in die HEVC-Encoder-Entwicklung: Im doom9-Forum gibt es x265 version 0.3+355-23d8d29c5242 (rev 3512).

    Wenn da Binaries (mit Quelltext) so nett verpackt veröffentlicht werden, könnte man fast glauben, dass die auch in einem testfähigen Zustand sind. Freiwillige?

    Abspielen sollte mit GPAC Nightly Builds möglich sein, Decodieren mit dem HM 11.0 Referenz-Decoder.
    __

    Mal einen Standardversuch laufen lassen:

    Code
    x265.exe sintel_trailer_1080.y4m -o sintel_trailer_1080.hevc

    Beschäftigt einen AMD Phenom-II X4 945 (3,00 GHz) mit etwa 80% und 3..4 Sekunden pro Frame.

    Das Verhältnis von 597198 kbps (Y4M-Ausgabe durch ffmpeg) zu ~220 kb/s (aktuelle Rate bei 20% Verarbeitung) stimmt mich aber skeptisch, was die Standard-Qualität (QP = 32) angeht.
    __

    Ja, es ist ein Graus, was da zu sehen ist. Aber stellenweise ist das Detaillevel doch überraschend. Wenn nicht die FullHD-Videofläche den Decoder überfordert.

    Code
    y4m  [info]: 1920x1080 24Hz, frames 0 - 1252 of 1253x265 [info]: detected SIMD architectures SSE2 SSE3x265 [info]: performance primitives: intrinsic assemblyx265 [info]: Main profile, Level-4 (Main tier)x265 [info]: thread pool with 4 threads, WPP enabledx265 [info]: CU size                      : 64x265 [info]: Max RQT depth inter / intra  : 3 / 3x265 [info]: ME method / range / maxmerge : star / 64 / 5x265 [info]: Keyframe min / max           : 24 / 24x265 [info]: WaveFrontSubstreams          : 17x265 [info]: QP                           : 32x265 [info]: enabled coding tools: rect amp rdo rdoq lft sao sao-lcu sign-hide tskip tskip-fast rdoqtsx265 [info]: frame I:53     kb/s: 1693.95  PSNR Mean: Y:52.171 U:62.779 V:62.546x265 [info]: frame P:1200   kb/s: 303.30   PSNR Mean: Y:47.707 U:60.231 V:59.938x265 [info]: global:        kb/s: 362.12   PSNR Mean: Y:47.895 U:60.339 V:60.049encoded 1253 frames in 4980.77s (0.25 fps), 362.90 kb/s

    Die bei GPAC 0.5.1 Nightly enthaltene MP4Box sollte man zum Multiplexen verwenden, damit Osmo4 es versteht (die aus der MeGUI stürzt ab):

    Code
    mp4box.exe -add sintel_trailer_1080.hevc#trackID=1:fps=24.0 -new sintel_trailer_1080_hevc.mp4

    Der nächste Versuch wird also auf jeden Fall eine feinere Quantisierung verwenden müssen. Und sicher eine kleinere Bildfläche (multithreaded scheint der Decoder in Osmo4 nicht zu sein, oder er skaliert nicht gut).

  • Eine weitere kleine Hürde ist, dass der Referenz-Decoder nur rohes YUV ausgibt, noch nicht mal Y4M (oder hab ich den Parameter übersehen?). Und RawSource ist momentan nicht kompatibel zu AviSynth 2.60 MT alpha 4 wegen des neuen Interface für den Cache-Modus (das Problem hatten die MaskTools 2 auch). Chikuzen müsste das bereits bemerkt haben...

Jetzt mitmachen!

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