H264 Codierproblem

  • Zeit spielt schließlich auch eine nicht unwichtige Rolle im Geschäft.

    Das ist wohl wahr. Aber heute ist das mit den aktuellen Prozessoren auch kein Problem mehr, meiner Meinung nach. Wir übergeben alles einem Rendersklaven im Netzwerk.
    Aber klar, wer nicht unbedingt eine Balance zwischen Qualität und Dateigröße sicherstellen muss, der ist mit einigen Hardware-Varianten gut genug bedient.
    Ich habe nie Tests mit Hardware-Encodern bei niedrigen Bitraten angestellt, aber bei mittleren hatte ich früher auch mit dem Firecoder und Quicksync in anderen Anwendungen keine Probleme, an die ich mich erinnern würde.
    Bei uns werden noch DVDs und Blu-rays professionell geauthored und da fallen die von Edius erzeugten Files eh raus, weil sie für diesen Zweck eher untauglich sind und gute Encoder hier besseres liefern. Das geht auch hervorragend mit dem x264-Encoder.
    Aber dass ich auf die Exporte aus Edius nicht mal für die Pressearbeit und Sichtungsversionen vertrauen kann, das nervt mich schon sehr.

  • Das geht auch hervorragend mit dem x264-Encoder.

    Mache ich auch so. Der x264 Encoder ist ja Bestandteil von Handbrake.


    Aber dass ich auf die Exporte aus Edius nicht mal für die Pressearbeit und Sichtungsversionen vertrauen kann, das nervt mich schon sehr.

    Willkommen im Club :prost:

    Mainboard Gigabyte Z790 UD AX, Intel Core i9 14900k, 32 GB DDR5 RAM, 1 x SSD 2TB, 1 x M.2 SSD 500GB (System), 1 x M.2 SSD 2GB, Geforce RTX3060 12GB, Blackmagic Intensity Pro 4K, RME HDSPe AIO, Windows 11 Pro-64 (23H2), Adobe Production Suite CS5, WaveLab 11, Prodad Adorage, Vitascene 3, Heroglyph 4, Acon Audio Restauration Suite 2, Acon Deverberate 3, Acon Extract Dialogue, Neat Video 5, NewBlue Amplify plus, Hide 1.5, Mercalli 6, Izotope RX10

  • Weil es gerade passte, habe ich ein neues Projekt des Vergleichs wegen in Handbrake und Edius (SW) als H264 MP4 herausgerendert.
    Man kann ganz gut die Dynamik des H264-Encoders erkennen, während der Edius-SW-Encoder recht gleichmütig daherkommt.
    Fairerweise muss gesagt werden, dass die Skalierungen unterschiedlich sind, weil der Edius-SW-Ecoder eine kurze Spitze von knapp 40 MBit mit drin hat.
    Die Skalierung anzupassen war beim Handbrake-Encoder offensichtlich nicht notwendig, weil dort die höchste Spitze bei knapp unter 30 MBit liegt.


  • "vertraue keiner Statistik, die du nicht selbst gefälscht hast" - :cool:
    ich würde gerne beide Kurven entweder oben mit max 50000 oder mit max 30000 sehen.

    Dann musst du dir oder mir ein Tool bauen, das die Skalierung nicht automatisch an die Spitzen-Bitrate anpasst.
    Hier wird nichts gefälscht, die Unterschiede sind trotzdem sehr gut erkennbar.
    Und die Resultate in der Vergangenheit sprechen gegen den Edius Software Encoder.

  • Die Skala ist zwar gestaucht, allerdings ist zu erkennen, dass die Dynamik für den Edius Encoder auch entstaucht sehr gedämpft wäre.
    Es ist deutlich erkennbar, dass der Encoder meist in der Nähe der durchschnittlich festgelegten Bitrate liegt und nur auf extreme Komplexitätsveränderungen kurzzeitig reagiert.


    Ich werde einen weiteren Test mit deutlich bewegterem Material machen, damit auch dem letzten klar ist, wie wenig effizient (abseits der ohnehin gezeigten visuellen Resultate) der Edius-Encoder ist.

  • Ich werde einen weiteren Test mit deutlich bewegterem Material machen, damit auch dem letzten klar ist, wie wenig effizient (abseits der ohnehin gezeigten visuellen Resultate) der Edius-Encoder ist.

    das ist nicht erforderlich. Ich wollte nur daraufhinweisen, dass die 2 gezeigten Skalen in dieser Form nicht zu Vergleichszwecken taugen.

  • Man kann ganz gut die Dynamik des H264-Encoders erkennen, während der Edius-SW-Encoder recht gleichmütig daherkommt.

    mein Einspruch bezieht sich auf diesen Satz. Es wird in den gezeigten viewern eine gestauchte Skalierung mit einer nicht gestauchten Skalierung verglichen. Daher wirkt die gestauchte gleichmütig.
    Unabhängig davon welche codierung die bessere ist.
    Alles ist gut.

  • ich würde gerne beide Kurven entweder oben mit max 50000 oder mit max 30000 sehen

    Dann wäre der Vergleich natürlich leichter, weil "augenfällig".


    Du musst aber nur die vom zeitlichen Ablauf her relativ übereinstimmenden stärksten "Ausschläge"nach oben oder unten im Auge behalten. Dann geht es auch so.

    • Bei der oberen Darstellung von Handbrake entspricht jede der waagerechten Linien 3.000 kbps, bei der unteren Darstellung von Edius entsprechend 5.000 kbps.
    • Die durchschittliche Bitrate liegt also bei beiden um die 10.000 kbps.
    • Wobei Edius mit 9.801 kbps eine rund 2% geringere durchschittliche Rate als Handbrake mit 9.987 kbps erreicht.
    • Dafür fallen aber die Spitzen im oberen Bereich bei Edius sehr viel stärker aus - z.B. ziemlich in der Mitte der stärkste Ausschlag bei Handbrake cs. 28.200 kbps, bei Edius 39.600 kbps.
    • Im unteren Bereich scheint der Unterschied nicht ganz so groß zu sein, aber Handbrake geht hier offenbar etwas tiefer als Edius - s. das letzte "Tal" im hinteren Drittel - geschätzt Handbrake unter 1.000 kbps / Edius um 2.500 kbps.
    • Der Steam aus Handbrake ist somit homogener als der von Edius, was bei einer Übertragung ggf. von Vorteil sein kann.
    • Dafür könnte es sein, dass Edius in bestimmten Bereichen = Details/Bewegungen genauer darstellt, aber das müsste man dann genau verglichen werden.
    • Insgesamt erzeugt Ediust (in diesem Fall) auch eine geringfügig kleinere Datei = Edius 8.411 GB / 8.547 GB Handbrake.



    Also ich finde das schon sehr interessant.



    Gruß
    Peter

    ASUS Prime X299-A II, i9-10980XE, 64 GB, Nvidia RTX 2080Ti, BMD UltraStudio 4K Mini, RME Fireface 400, Win 11 Pro , EDIUS 11 WG

    Steinberg Cubase Pro, WaveLab Pro, SpectraLayers Pro

  • mein Einspruch bezieht sich auf diesen Satz. Es wird in den gezeigten viewern eine gestauchte Skalierung mit einer nicht gestauchten Skalierung verglichen. Daher wirkt die gestauchte gleichmütig.Unabhängig davon welche codierung die bessere ist.
    Alles ist gut.

    Schon klar, aber du könntest die Kurve in Photoshop entzerren und die Edius-Kurve würde noch immer sehr gleichmütig aussehen.

  • Dafür fallen aber die Spitzen im oberen Bereich bei Edius sehr viel stärker aus - z.B. ziemlich in der Mitte der stärkste Ausschlag bei Handbrake cs. 28.200 kbps, bei Edius 39.600 kbps.

    Ja und hier vermute ich eher, dass der Edius-Encoder Bitrate verschwendet.

    Im unteren Bereich scheint der Unterschied nicht ganz so groß zu sein, aber Handbrake geht hier offenbar etwas tiefer als Edius - s. das letzte "Tal" im hinteren Drittel - geschätzt Handbrake unter 1.000 kbps / Edius um 2.500 kbps.

    Ja, x264 bestimmt nach dem Analysevorgang einen Qualitätsfaktor, der über die komplette Länge des Films gehalten wird.

    Der Stream aus Handbrake ist somit homogener als der von Edius, was bei einer Übertragung ggf. von Vorteil sein kann.

    Das kann man so nicht sagen, der Graph ist durch die Bank weg deutlich unruhiger als der des Edius-Encoders, was ich der Komplexität der jeweiligen Szene zurechne.

    Dafür könnte es sein, dass Edius in bestimmten Bereichen = Details/Bewegungen genauer darstellt, aber das müsste man dann genau verglichen werden.

    Davon gehe ich ehrlich gesagt nicht aus. Ich denke eher, das Edius mehr Bits verballert um eine ähnliche Qualität zu erreichen.
    Ich werde einen Test mit bewegterem Material machen. Dieses Projekt war geprägt von eher wenig bewegten Interviewszenen.


    Gruß Jim

  • Auf die unterschiedlichen Skalierungen habe ich selbst hingewiesen, darauf kann ich keinen Einfluss nehmen.

    Was hast Du da verglichen VBR mit CBR oder CBR mit CBR oder VBR mit VBR?
    Welche Bitraten sind jeweils in den beiden Programmen eingestellt worden, also min./max. oder max. bei CBR?
    Welche Kodierung gefällt einer neutralen Person besser auf dem TV, abgesehen mal vom dem was
    der Bitraten Viewer da anzeigt?

    Servus, Pee
    EDIUS 11 WG, DVR 19 Studio, Mercalli V6 SAL, ASUS Prime Z390-P, i9-9900K mit Intel HD-630, 32GB RAM, SSD-System + SSD-Schnitt, Diverse FP,
    NVIDIA GF-RTX 2060 Super 8GB, W10Pro(22H2), 32" LG PC-Monitor, 32" HDR(HLG)-Vorschau TV per BM Intensity Pro 4K
    Sony ZV-1 mit Zhiyun Crane M2 , Pana FZ-300, GoPro Hero 7 Black, DJI Pocket 2, DJI Mavic Mini, Huawei Mate 20 Pro

  • Ich habe mal einen CBR-Vergleich gemacht mit identischen max. Bitraten für EDIUS und DaVinci Resolve 18,
    hier sieht das so aus im Bitraten Viewer:


    Optisch auf dem TV kann ich da keinen Unterschied erkennen... 8)



    Servus, Pee
    EDIUS 11 WG, DVR 19 Studio, Mercalli V6 SAL, ASUS Prime Z390-P, i9-9900K mit Intel HD-630, 32GB RAM, SSD-System + SSD-Schnitt, Diverse FP,
    NVIDIA GF-RTX 2060 Super 8GB, W10Pro(22H2), 32" LG PC-Monitor, 32" HDR(HLG)-Vorschau TV per BM Intensity Pro 4K
    Sony ZV-1 mit Zhiyun Crane M2 , Pana FZ-300, GoPro Hero 7 Black, DJI Pocket 2, DJI Mavic Mini, Huawei Mate 20 Pro

  • Was hast Du da verglichen VBR mit CBR oder CBR mit CBR oder VBR mit VBR?
    Welche Bitraten sind jeweils in den beiden Programmen eingestellt worden, also min./max. oder max. bei CBR?
    Welche Kodierung gefällt einer neutralen Person besser auf dem TV besser abgesehen mal vom dem was
    der Bitraten Viewer da anzeigt?

    Ich encode immer VBR.
    Bei Handbrake gibt es keine maximale Bitrate.
    Bei Edius war bis zu 40 MBit eingestellt.


    Was Edius an Encodings erzeugt hat, hatte ich ja schon mal weiter oben gepostet.
    Diese Probleme sind mein Hauptproblem mit dem Edius-Encoder, sie lassen immer einen letzten Zweifel an der Qualität.
    Was nicht persönlich komplett gescreent wurde steht immer im Zweifel.


    Dass eine neutrale Person im Zweifel "Tearings" und Blockartefakte nicht mag, dürfte nicht angezweifelt werden, oder?

  • Ich habe mal einen CBR-Vergleich gemacht mit identischen max. Bitraten für EDIUS und DaVinci Resolve 18,
    hier sieht das so aus im Bitraten Viewer:


    Optisch auf dem TV kann ich da keinen Unterschied erkennen... 8)

    Nun ist CBR auch wirklich keine Disziplin, in der ein Encoder herausgefordert wird, wenn er nur genug Bitrate verballern darf.

  • Ja, x264 bestimmt nach dem Analysevorgang einen Qualitätsfaktor, der über die komplette Länge des Films gehalten wird.

    Das ist ja eben einer der Vorteile bei X.264 gegenüber.
    Dafür ist X.264 aber halt in En- und Decodierung etwas anspruchsvoller = rechenintensiver.



    Das kann man so nicht sagen, der Graph ist durch die Bank weg deutlich unruhiger als der des Edius-Encoders, was ich der Komplexität der jeweiligen Szene zurechne.

    M.E. schon.
    Es gibt bei Handbrake zwar im Durchschnittlichen etwas mehr Schwankungen, aber doch in einem ziemlich schmalen Bereich von 10.000 kbps bis etwas über 12.000 kbps. Und die Spitzen sind dort eben sehr viel geringer.
    Bei Edius hast Du zwar offenbar einen etwas schmaleren durchschnittlichen Schwankungsbereich von vielleich nur 9.000 kbps bis etwa 10.000 kbps, dafür aber halt mit extrem höheren Spitzen.


    Insoweit finde ich den Stream aus Handbrake schon homogener = gleichförmiger. Bei Handbrake gibt es zwar von der Anzahl her mehr Schwankung, aber eben in einem doch deutlich engeren Bandbereich.




    Davon gehe ich ehrlich gesagt nicht aus. Ich denke eher, das Edius mehr Bits verballert um eine ähnliche Qualität zu erreichen.

    Gut, dass ist natürlich anhand der reinen Graphen nicht zu sagen. Hier müsste dann (wie schon geschrieben) ein direkter Vergleich des Darstellung erfolgen, was ja evtl. über die Zeitangabe möglich wäre.




    Ich werde einen Test mit bewegterem Material machen.

    Wäre interessant.
    Ich vermute, dass Edius dort dann mit häufigeren Spitzenwerten auftreten wird.





    Nachtrag:


    Nun ist CBR auch wirklich keine Disziplin, in der ein Encoder herausgefordert wird, wenn er nur genug Bitrate verballern darf.

    Zumal ja die Vorteile von Codecs wie H.264 / H.265 auch nur bei VBR wirklich ausgenutzt werden, indem halt nach tatsächlichem Bedarf und nicht einem generell festgelegten Wert codiert wird.


    Es gibt zwar durchaus Fälle in denen CBR eine gute Option ist, aber grundsätzlich sollte bei dieser Art Codecs doch eher VBR angewendet werden.



    Gruß
    Peter

    ASUS Prime X299-A II, i9-10980XE, 64 GB, Nvidia RTX 2080Ti, BMD UltraStudio 4K Mini, RME Fireface 400, Win 11 Pro , EDIUS 11 WG

    Steinberg Cubase Pro, WaveLab Pro, SpectraLayers Pro

    Einmal editiert, zuletzt von gurlt ()

  • Ich mache noch mal einen Test mit wirklich bewegtem Material und vielen Schnitten, am besten mit einem Trailer.
    Der im letzten Test zugrundeliegende Film ist das Portrait eines Musiker im Bereich Klassik, insofern war das Ausgangsmaterial nicht ideal für einen anspruchsvolleren Test, die crazy Spitze kann ich mir auch wirklich nicht erklären.

  • die crazy Spitze kann ich mir auch wirklich nicht erklären.

    Nun sie entspricht halt dem von Dir in Edius gewählten Max.-Wert. Insoweit eigentlich ok.


    Warum jetzt ausgerechnet an diesem Punkt und an einer anderen Stelle kurz vor Ende in beiden Encodern sehr hohe Spitzenwerte entstehen, könnte man halt nur eine Betrachtung des Bildinhaltes erraten. :nw:

    ASUS Prime X299-A II, i9-10980XE, 64 GB, Nvidia RTX 2080Ti, BMD UltraStudio 4K Mini, RME Fireface 400, Win 11 Pro , EDIUS 11 WG

    Steinberg Cubase Pro, WaveLab Pro, SpectraLayers Pro