Beiträge von Jim_Pansen

Zitat von gurlt

Streaming ist halt inzwischen "der" Vertriebsweg und sehr bequem.

Ich mag es nicht, nutze es selbst auch nicht.
Die Wertschätzung dem Medium Film gegenüber ist eine andere, es gibt kaum Besonderes mehr in dieser medialen Flut.
Abgesehen davon geht auch etwas bei der Präsentation verloren, die Aufführungsqualität sinkt wieder, die Ansprüche zu einem großen Teil auch.
Viele schauen ja Netflix und Co auf ihrem Laptop. Kinoerlebnis? Jede Blu-ray ist von besserer Bildqualität als die Streams bei Netflix und Co.

Zitat von gurlt

Richtig, wobei dies aber nicht unbedingt H.264 Streams sind.

Beim ÖRR habe ich noch nichts anderes gefunden, zumindest nicht mit Mediathekview. Ich meine, mich auch an VP8-Streams (oder VP9?) über die Websites zu erinnern.
Bei Netflix könnte für 4k H265 zum Einsatz kommen. Aber damit habe ich eher nichts zu tun, ich liefere da nur dann und wann an. Und das sind dann ProResHQ422-Dateien.

Zitat von gurlt

Hier hängt es aber halt auch davon ab wie sich das System verhält und was da sonst noch (Hintergrundprozesse) so los/reserviert ist.

Naja, alle anderen Prozesse funktionieren ja. Auf zwei verschiedenen Systemen gibt es ähnliche Probleme.

Zitat von gurlt

Allerdings finde ich dann auch bei 24 fps die durchschnittlichen 10.000 kbps als etwas niedrig, auch wenn Handbrake das durchaus packen kann.

Nein, das ist für Screener durchaus üblich. 10 GB bei einem Spielfilm sind ja zu diesem Zweck nicht gerade wenig. Ein Limit bei der Qualität + Timecode ist da manchmal durchaus sogar gewollt.
Aber sogar Streams bei Netflix und Co. haben oft erstaunlich niedrige Bitraten. In der Mediathek der ÖRR haben die Streams nicht selten 2,5 MBit bei 1280x720.

Zitat von gurlt

Mir fällt da auf, dass aus

• Handbrake mit 25 fps PAL,
• Edius mit 24 fps NTSC

encodiert!!!
Insoweit könnte die Blockbildung auch mit der geänderten Framerate und den dafür erstellen Zwischenbildern im Zusammenhang stehen.

Nein, damit hängt es nicht zusammen. Das ist leider das Haar in der Suppe, ich habe schon damit gerechnet, dass das noch jemand anspricht.
Das Material ist nativ 24p und Handbrake war noch dummerweise auf 25fps gesetzt. Aber Handbrake blockt ja nicht, kein Problem.
Auf das gute visuelle Resultat und die Bitratenverteilung bei Handbrake hatte das keinen Einfluss.

Vielmehr geht es ja um die Einbrüche des EDIUS-Software-Encoders und die generelle Frage, warum GV zu keinem Codec (MPEG2, H264, H265) einen 2-pass Software-Encoder entwickelt hat.

Hingegen der Edius-Hardware-Encoder, flache Kurve bei der Bitrate, aber wenigstens blockt der nicht!

Der Edius-Software-Encoder auf einem zweiten Rechner:
Der blockt auch, nur anders, es gibt halt ganz vorn noch ein Bitraten-Tal.

Es ist dann doch kein Trailer geworden, sondern ein Ausschnitt aus einem Film, der eigentlich aus sehr ruhigen Szenen besteht, in dem es aber eine Passage gibt, in dem stroboskopartige Lichtverhältnisse existieren, also kurz hintereinander aufflackerndes Licht. Das sind perfekt Szenen, bei denen sich herausstellt, ob ein Encoder Befriedigendes leistet.

Das Resultat in Edius sind zwei dramatische Zusammenbrüche der Bitrate, sowie Blockbildung mit Tearing-Effekten!
In Handbrake ist alles smooth, weil der Encoder mit effektiven Algorithmen die Bitrate auch effektiv nutzt.

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.

Zitat von Pee

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...

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

Zitat von Pee

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?

Zitat von gurlt

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.

Zitat von gurlt

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.

Zitat von gurlt

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.

Zitat von gurlt

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

Zitat von lucifär

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.

Zitat von lucifär

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

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

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.

Zitat von lucifär

"vertraue keiner Statistik, die du nicht selbst gefälscht hast" -
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.

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.

Zitat von Grauer Tiger

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.

Zitat von Grauer Tiger

Leider hält sich das Märchen vom "besseren Softwareencoding" hartnäckig. Ich habe noch nie bessere Ergebnisse mit Softwareencoding gehabt.

Sagen wir es so, das, was da als Hardware abgebildet wird, sind ja auch nur Algorithmen. Insofern sind die Encodings eben so gut, wie es die abgebildeten Algorithmen sind.

Software-Encoder haben im Gegensatz zu QuickSync und Co. mehr Möglichkeiten, weil meistens nicht alle Aspekte der Spezifikation in der Hardware abgebildet werden, in unserem Fall ist es der 2-pass Modus.
Wenn ein Hardware-Encoder schnell und zuverlässig auf sich verändernde Komplexitäten reagieren kann, kann er über einen vorher festgelegten Constant Quality Factor jederzeit die Bitrate anpassen und gute Ergebnisse liefern.
Bei 1-pass steht dann aber die resultierende Größe in Frage, weil für den Encoder nicht abzusehen ist, wie lang und wie komplex das Material ist.
Software hat den Vorteil, man kann sie einfach schneller anpassen.

Jim

Zitat von bego1969

Das klingt alles wirklich nicht gut und sieht auch nicht gut aus
Daher
!Diese H264 Verbesserung wäre dann wohl ein wichtiger Punkt für die "Top wanted Edius features "- Liste!
Eine Überarbeitung dieses Encoders scheint auf jeden Fall unvermeidbar, nach deinen Ergebnissen und Tests.

Ich muss ganz ehrlich sagen, die meisten werden diese Probleme nicht haben, weil sie:

1. in der Regel auf Quicksync-Hardware-Encoding setzen werden und damit vom Software-Algorithmus nicht betroffen sind, auch wenn dieser Modus keinen 2-pass Modus hat. Ob es da derartige Einbrüche gibt, habe ich nicht getestet, da die Rechner, die ich nutze, kein Quicksync zur Verfügung stellen.

2. werden die wenigsten User Material nutzen, das den Encoder enorm stresst (Licht, das an und aus geht oder schnelle, hektische Bewegungsabläufe und Schnitte mit abwechselnden Lichtverhältnissen).

3. werden die meisten User ihren Exporten immer relativ hohe Bitraten verpassen, weil es im Zweifel nicht so sehr darauf ankommt.

In den Beispiel-Screenshots ging es um einen Screener, der bei der FSK eingereicht werden sollte und damals eine Zielgröße von 3 GB nicht übersteigen sollte.

Ich will einfach nur einen Encoder, der die gegebene Bitrate, die sich aus der Größenvorgabe und der Laufzeit ergibt, effizient nutzt und auch eine gewisse Robustheit für schwierig Szenen hat. Und das geht nur mit einem 2-pass Encoder.

Ich nutze mittlerweile andere, teilweise kostenlose Tools, die das deutlich besser können. Ich spiele alles vorher als GV HQ Codec aus und jage es dann durch diese Encoder, die dank FFMPEG- und LibAV-Inplementierung den GV Codec direkt decodieren können. Ohne die Arbeit der Open-Source-Community ginge das mutmaßlich bis heute nicht.

Gruß Jim

Nur um es mal zu visualisieren, ich habe einmal mit einer kritischen Szene einen Vergleichstest zwischen Edius 9.5 Software Encoder und dem in dieser Version noch funktionalen Quicktime-Exporter mit gleicher variablen Bitrate (1280x720@24p bei 3,5 MBit) exportiert. Die Resultate des Edius-Software-Encoders zeigen ein absolutes Desaster! Der QuickTime-Exporter machte keinerlei Theater und bildete alles zuverlässig in bestmöglicher Qualität ab!

An den Screenshots des Bitratenviewers ist zu sehen, wie der Edius-Encoder komplett einbricht, die Bitrate über einen Zeitraum von mehreren Sekunden gen NULL geht, was die Darstellungsqualität erklärt. Der QuickTime-H264-Exporter sieht kein Problem und verteilt Bitrate dahin, wo sie benötigt wird, weil der durch den vorherigen Analysevorgang eine Kennlinie der Bild-Komplexität zur Verteilung der Bitrate ermittelt hat, um Bits und Bites ökonomisch im Sinne der durchschnittlichen Bitrate und Zielgröße so zu verteilen, dass die bestemögliche Bildquaölität getroffen werden kann.

Ich kann es mir jedenfalls nicht mehr leisten, solch unprofessionelle Ergebnisse beim Kunden auflaufen zu lassen und nutze daher Edius nicht mehr für irgendwelche H264-Encodings. Durch den Wegfall des Quicktime-Exporters in Version X gibt es für mich auch keinerlei Gründe mehr, upzugraden.

Da ich solche Ergebnisse auch schon in Blu-ray-Exports hatte, ist Edius nicht mehr das Mittel der Wahl!

GrassValley weigert sich konsequent seit Jahren, Encoder zu implementieren, die die Möglichkeiten bei komprimierten Formaten sinnvoll ausnutzen. So war das schon beim MPEG2-Exporter (auch nur 1-pass und für enge Projekte mit genauem Bitbudgeting ungeeignet), nachdem der ProCoder nicht mehr unterstützt wurde, der ein hervorragender Encoder für MPEG2 (Multipass-tauglich und komplex bei der Parametrisierung) war. Beim H264-Encoder blieb man weiter unambitioniert, aus meiner Sicht sogar nachlässig.

Wer beim Edius-H264-Encoder eine Zielbitrate anvisiert, um eine bestimmte Qualität bei einer bestimmten Dateigröße zu erreichen, macht eigentlich eine Wette. Man muss hoffen, dass das Material nicht zu komplex ist, damit der Edius-Exporter nicht ins stottern kommt. Der Encoder wurde so designt, dass er die gewünschte durchschnittlich gesetzte Zielbitrate regelmäßig und systematisch unterschreitet, damit am Ende die avisierte Dateigröße wenigstens nicht überschritten wird (für Blu-ray und DVD notwendig).

Die Strategie des Encoders ist unbekannt und wie der Bitrate-Viewer zeigt, eher fragwürdig.
Wer in einem 1-pass-Encoding-Vorgang bei variabler Bitrate eine durchschnittliche Zielbitrate und eine bestimmte Zielgröße erreichen will, muss das letztendlich zu Lasten der Qualität tun, denn die Komplexität des Materials ist dem Encoder vollständig unbekannt.

Während ein CBR-Mode viel Bitrate verschwendet, wenn sie gar nicht benötigt wird und dann in Momenten höchster Komplexität nicht auf Spitzen reagieren darf, weil die Bitrate nach oben hin limitiert ist, kann im Gegensatz dazu der VBR-Mode in beide Richtungen auf die Gegebenheiten reagieren. Mit einem vorgeschalteten Analysevorgang kann der Encoder einen Qualitätsfaktor auf Basis der Komplexität errechnen, nach welchem er die Bitrate gewichtet zur Verfügung stellt, um den errechneten Qualitätsfaktor visuell zu erreichen. Das ist mit dem Edius-Encoder in keiner Weise möglich.

Der Edius-Encoder muss den Encodingvorgang mit einer durchschnittlichen Bitrate beginnen. Um die Zielgröße und Zielbitrate wenigstens ungefähr zu erreichen, weicht er dann nur noch marginal nach oben oder nach unten aus. Ein VBR-Encoding eines ordentlichen 2-pass Encoders sieht im Bitrate-Viewer völlig anders aus, als ein VBR-Encoding mit dem 1-pass-Encoder in Edius. Während ersterer einen Graphen erzeugt, der Berge und Täler mit großer Amplitude zeigt, erinnert der 1-pass Encoder eher an ein CBR mit leichten Abweichungen nach oben oder unten.

Professionell ist der Encoder in Edius jedenfalls nicht und er reicht noch nicht einmal für Timecode-Sichtungsversionen aus, wie man an den Screenshots sehen kann.

Jim