To the edge: Youtube Qualität

[robbie]

Hallo liebe Slashcamer!

Seit langem wieder mal ein Beitrag von mir, diesmal eine Mischung aus Erfahrungsbericht, Analyse und Frage an die Crowd. - Thema: Youtube Qualität.

Lt. Youtube sind die "optimalen" Upload Einstellungen 1080p h.264 mit 8Mbit. Soweit so gut. Das sieht bei meinen Qualiätsanforderungen doch recht mies aus. Vimeo ist besser, das wissen wir, aber natürlich erreicht man auf Youtube mehr Views.
Dass es auch auf Youtube definitv besser geht, beweisen viele Videos, die wir uns ansehen können. zB dieses hier:

Selbst wenn ich ein Video hochlade, das mit der selben Kamera gedreht wurde, erreicht YT nicht annähernd die Qualität.

Das führt zu folgendem Schluss:
1. Vevo hat bessere Qualität als der Standard-Nutzer
2. Mit den Standard-Vorgaben für Upload bekomme ich das nicht hin
3. Wie kann man das Problem lösen?

YT encodiert nach dem Upload nochmals auf den V9-Codec, soweit ich das bis jetzt recherchieren konnte.
YT akzeptiert auch andere Formate. zB DNxHD

Ich habe ein Testfile in DNxHD 180 hochgeladen und siehe da, die Qualität ist tatsächlich um Welten besser.

Da ich selbst nicht in 4K produziere wäre das natürlich ein - wenn auch sinnloser - Umweg.

Ich bitte um Input von euch. Ich möchte in den nächsten Tagen in diesem Thread Testmaterial sammeln, Tipps und Tricks zusammenführen und bin auf eure Inputs gespannt.
Ach ja - auch wegen Taylor Swift: In diesem Beitrag geht es rein um die technische Qualität, nicht um den Inhalt ;)

[klusterdegenerierung]

Hallo Robbie, sehr interessant und gut zu wissen, auch wegen meiner Kunden.
Das heißt, bezogen auf h264 hiese das, das ich 8MBit oder 100Mbit hochladen kann, aber nach der YT Prozedur,
kommt das selbe bei raus?

Wie konntest Du einen Unterschied zwischen hochgeladenem h264 & DNxHD nach der YT Prozedur sicher feststellen?

[Starshine Pictures]

8 Mbit sind als Ausgangsmaterial für einen Youtube Upload natürlich viel zu wenig. Ich denke die geben diese Empfehlung raus um Serverplatz zu sparen und Low Quality Content nicht auszuschliessen. Lade immer in der dir höchst möglichen Bitrate hoch! Ich nehme mindestens 35 Mbit für FullHD Material. Sinnvoll sind 120% der Bitrate deines original Kameramaterials. Also wenn deine Kamera 20Mbit h264 aufzeichnet, dann rendere deinen fertigen Film in 24 Mbit Zielbitrate und gib noch Puffer drauf, also maximale Bitrate zum Beispiel 35 Mbit. Dies mache ich weil Premiere eine, nuja, unterdurchschnittliche Renderqualität im Verhältnis zur Bitrate hat.


Grüsse, Stephan

[blueplanet]

Sinnvoll sind 120% der Bitrate deines original Kameramaterials. Also wenn deine Kamera 20Mbit h264 aufzeichnet, dann rendere deinen fertigen Film in 24 Mbit Zielbitrate und gib noch Puffer drauf, also maximale Bitrate zum Beispiel 35 Mbit. Dies mache ich weil Premiere eine, nuja, unterdurchschnittliche Renderqualität im Verhältnis zur Bitrate hat.
Grüsse, Stephan

...eine ähnliche Diskussion (von mir angezettelt ;) hatten wir bereits. Also: Sinn oder Unsinn von exorbitanten Bitraten. Deshalb meine Frage an Dich: was machst Du wenn die Kamera 50Mbit und mehr produziert, produzieren (kann)? Meine Erfahrung: kaum eine Mediaplayer extern oder intern (über USB zu gespielt) schafft mehr als 35MBit/s "ruckelfrei" zu verarbeiten. Rein optisch betrachtet und selbst bei sehr "bewegtem" Material sind somit 35Mbit/s nicht nur technisch die Obergrenze. Und youtube ist für den "Massenkonsum" konzipiert. Es kann keine "Anschruchs/Testplattform" im eigentlichen sein/werden.

beste Grüße
Jens

[Frank Glencairn]

Es gab mal ein keines Programm, daß HD Material auf 4k aufgeblasen, und speziell für YT verpackt hat.
Die Idee dahinter ist, daß 4K Material beim recodieren von Anfang an mehr Bandbreite bei YT bekommt, und deshalb besser aussieht, wenn man es auf YT in HD abspielt.

Hat auch tatsächlich recht gut funktioniert.

Leider ist es nicht mehr erhältlich - so wie ich es verstanden habe aus lizenzrechtlichen Gründen, da es nebenher auch ProRes auf einem Win PC ausgeben konnte, daß von "echtem" ProRes nicht zu unterscheiden war.

Aber womöglich kann man es noch irgendwo in den Weiten des Netzes finden.
Es hieß "FourK"

Alternativ vielleicht gleich in V9 kodieren - meine Tests waren allerdings nicht überzeugend, ist aber auch schon ne ganze Weile her, womöglich hat sich da zwischenzeitlich was verbessert.

[mash_gh4]

es gibt zu dieser frage einen ziemlich interessanten artikel von jan ozer:

http://streaminglearningcenter.com/arti ... files.html

darin wird an hand von empirischen tests aufgezeigt, wie wenig tatsächlichen gewinn all diese userseitigen kunstgriffe bzw. übertriebenen datenraten bringen.

wenn man wirklich höhere qualität haben will, ist vermutlich self-hosting und die nuztzung deutlich höherer maximaler auslieferungsbadbreiten in den HLS/DASH bündeln vermutlich die wesentlich zielführendere strategie.

[robbie]

Das mit 4K ist definitiv auch für mich einen Test wert. Mein Schnittplatz ist gerade belegt, aber mal schauen was dabei herauskommt.
Mein Ausgangsmaterial ist in 50% der Fälle XDCAMHD422 mit 50Mbit, der Rest XAVC. Das frisst youtube nicht. DNxHD und ProRes funktionieren und geben eine deutlich bessere Qualität wieder als .h264. .h264 hab ich mit datenraten bis 50Mbit probiert. Ab 20Mbit gibt es hier visuell keinen Unterschied mehr.

Für mich gilt es jetzt den DnxHd oder ProRes Codec zu finden, welcher die beste 1080p Qualität auf Youtube liefert.
Parallel dazu gibt es einen Test mit Upgescaltem 4K Material und dann in HD wiedergegeben.

[dienstag_01]

DNxHD und ProRes funktionieren und geben eine deutlich bessere Qualität wieder als .h264.

Das kannst du hier gern mal zeigen ;)

[beiti]

was machst Du wenn die Kamera 50Mbit und mehr produziert, produzieren (kann)? Meine Erfahrung: kaum eine Mediaplayer extern oder intern (über USB zu gespielt) schafft mehr als 35MBit/s "ruckelfrei" zu verarbeiten. Rein optisch betrachtet und selbst bei sehr "bewegtem" Material sind somit 35Mbit/s nicht nur technisch die Obergrenze. Und youtube ist für den "Massenkonsum" konzipiert. Es kann keine "Anschruchs/Testplattform" im eigentlichen sein/werden.

Die Datenrate, die man fürs direkte Abspielen z. B. vom USB-Stick wählt ist, etwas völlig Anderes als die Datenrate, die man zu YouTube hochladen sollte.

Wenn man eine Datei fürs direkte Abspielen komprimiert, sind Bitraten über 20 MBit/s in der Tat nur selten nützlich und manchmal sogar hinderlich.

Bei YouTube hat man ein ganz eigenes Problem: YouTube komprimiert hochgeladene Videos in jedem Fall nochmal neu (und zwar in nicht allzu hoher Datenrate). Aber leider ist die YouTube-eigene Komprimierung sehr eigenwillig und ihre Fehler addieren sich oft zu denen, die man bereits in der eigenen Komprimierung eingefügt hat. Es könnte auch sein, dass die YouTube-Komprimierung empfindlich auf schon vorhandene Komprimierungsfehler reagiert und daraus dann neue, größere Artefakte macht.
Daher lohnt es tatsächlich, eine hohe Qualität (z. B. 50 MBit/s in H.264) hochzuladen. YouTube dampft das dann zwar auf einen Bruchteil davon ein, aber das Endresultat hat dann trotzdem weniger Artfefakte als in dem Fall, wo man selber nur 8 oder 10 MBit/s hochgeladen hat.
Ich habe das mal mit kritischem Material durchgetestet, und es macht wirklich einen großen Unterschied aus - wobei natürlich nicht jedes Material kritisch ist. ;)

[mash_gh4]

DNxHD und ProRes funktionieren und geben eine deutlich bessere Qualität wieder als .h264.

wie die messwerte im oben verlinkten artikel ganz eindeutig belegen, dürfte DNxHD und ProRes sich in diesen fällen in wahrheit als ziemlich nachteilig und ineffizient erweisen.

wie gesagt -- die zahlen in den entsprechenden empirischen test scheinen mir hier mehr auszusagen als jede noch so felsenfeste subjektive überzeugung. (wenn mir allerdings jemand nachvollziehbare PSNR/SSIM messwerte zeigen kann, die das gegenteil belegen, wäre ich ihm natürlich dankbar.)



ähnlich verhält es sich übrigens auch mit 4:2:2-material, dass in den mesiten browsern nicht abgespielt werden kann, und daher ohnehin beim neuerlichen enkodieren durch die serviceprovider fast zwingend rausfliegt bzw. in 4:2:0 umgerechnet wird, um die kompatibilität zu wahren.

youtube würde ich bzgl. der qualität nicht unterschätzen. im gegensatz zu vielen anderen anbietern verwenden man dort für die auslieferung VP9 statt h.264 (nur diverse apple browser unterstützt das nicht, was einen rückgriff auf h.264 erfordert). das bringt bei gleicher bandbreite eine deutlich höhere qualität bzw. eine spürbar befriedigendere wiedergabe über schlechte leitungen. VP9 ist in dieser hinsicht relativ nah an h.265 dran, welches halt aus linzenpolitischen gründen weiterhin in praktisch keinem browser zur verfügung steht. eine wirkliche verbesserung dieses zustand ist vermutlich erst in ca. einem jahr zu erwarten, wenn AOM AV1 breitere unterstützung in den gebräuchlicher browsern finden wird.

[dienstag_01]

was machst Du wenn die Kamera 50Mbit und mehr produziert, produzieren (kann)? Meine Erfahrung: kaum eine Mediaplayer extern oder intern (über USB zu gespielt) schafft mehr als 35MBit/s "ruckelfrei" zu verarbeiten. Rein optisch betrachtet und selbst bei sehr "bewegtem" Material sind somit 35Mbit/s nicht nur technisch die Obergrenze. Und youtube ist für den "Massenkonsum" konzipiert. Es kann keine "Anschruchs/Testplattform" im eigentlichen sein/werden.

Die Datenrate, die man fürs direkte Abspielen z. B. vom USB-Stick wählt ist, etwas völlig Anderes als die Datenrate, die man zu YouTube hochladen sollte.

Wenn man eine Datei fürs direkte Abspielen komprimiert, sind Bitraten über 20 MBit/s in der Tat nur selten nützlich und manchmal sogar hinderlich.

Bei YouTube hat man ein ganz eigenes Problem: YouTube komprimiert hochgeladene Videos in jedem Fall nochmal neu (und zwar in nicht allzu hoher Datenrate). Aber leider ist die YouTube-eigene Komprimierung sehr eigenwillig und ihre Fehler addieren sich oft zu denen, die man bereits in der eigenen Komprimierung eingefügt hat. Es könnte auch sein, dass die YouTube-Komprimierung empfindlich auf schon vorhandene Komprimierungsfehler reagiert und daraus dann neue, größere Artefakte macht.
Daher lohnt es tatsächlich, eine hohe Qualität (z. B. 50 MBit/s in H.264) hochzuladen. YouTube dampft das dann zwar auf einen Bruchteil davon ein, aber das Endresultat hat dann trotzdem weniger Artfefakte als in dem Fall, wo man selber nur 8 oder 10 MBit/s hochgeladen hat.
Ich habe das mal mit kritischem Material durchgetestet, und es macht wirklich einen großen Unterschied aus - wobei natürlich nicht jedes Material kritisch ist. ;)

Auch hier gilt, zeigen. Ich halte das nämlich nach einer ganzen Reihe eigener Test für totalen Quatsch (ich meine speziell die angeblich bessere Qualität bei 50mbit)

Edit: nur mal zum Vergleich, ich lade VBR 16/20 hoch (1080p25), und behaupte, da schon gigantischen Puffer zu haben.

[Starshine Pictures]

Es kommt eben immer auch auf das Material selbst an. Zum Beispiel einen spiegelnden See mit kleinen Wellen und drüber einen grossen Ast mit vielen Blättern der sich im Wind wiegt. Und dann noch etwas Grain als Effekt drüber. Das ist der Tod für jede schmale Bitrate. Da geh ich lieber auf Nummer sicher und beschneide die Qualität nicht schon bei mir. Und wie gesagt, Premiere ist nicht wirklich super um h264 sauber zu codieren. Es braucht einfach mehr Fleisch dran. Die 24 Mbit aus meiner C100 sehen auch deutlich besser aus als das was mit 24 Mbit aus Premiere raus kommt. H265 sieht da schon besser aus. Aber das wird von Youtube gar nicht akzeptiert, und von Vimeo nur mit drastischen Farbunterschieden umkodiert.

[dienstag_01]

Es kommt eben immer auch auf das Material selbst an. Zum Beispiel einen spiegelnden See mit kleinen Wellen und drüber einen grossen Ast mit vielen Blättern der sich im Wind wiegt. Und dann noch etwas Grain als Effekt drüber. Das ist der Tod für jede schmale Bitrate. Da geh ich lieber auf Nummer sicher und beschneide die Qualität nicht schon bei mir. Und wie gesagt, Premiere ist nicht wirklich super um h264 sauber zu codieren. Es braucht einfach mehr Fleisch dran. Die 24 Mbit aus meiner C100 sehen auch deutlich besser aus als das was mit 24 Mbit aus Premiere raus kommt. H265 sieht da schon besser aus. Aber das wird von Youtube gar nicht akteptiert, und von Vimeo nur mit drastischen Farbunterschieden umkodiert.

Auch du liegst hier daneben, und zwar komplett.
Aber kannst es ja mal zeigen ;)

[beiti]

Auch hier gilt, zeigen. Ich halte das nämlich nach einer ganzen Reihe eigener Test für totalen Quatsch (ich meine speziell die angeblich bessere Qualität bei 50mbit)

Was "bessere Qualität" ist, darüber mag man streiten. Es ging einfach um die Frage, ob man mit einer höheren Upload-Bitrate weniger Artefakte in der fertigen YouTube-Version kriegt.

Eine meiner Versuche steht zufällig noch bei YouTube. Es war ein Versuch mit besonders kritischem Material (Actioncam-Fahraufnahmen vom Fahrrad aus). Da kommt jeder Interframe-Codec ins Straucheln, weil sich dauernd die ganze Perspektive ändert und kaum was da ist, was inhaltlich gleich bleibt oder sich zwischen den Frames nur verschiebt.
Ich habe den Clip zum Vergleich einmal mit 10 MBit und einmal mit 50 MBit hochgeladen.
Beide YouTube-Versionen sind voll von Flächen-Artefakten. Aber zum Beispiel die Bäume am Rand und auch der Wald im Hintergrund sind in der 50-Mbit-Version zumindest etwas besser als in der 10-Mbit-Version.
Schön sind beide YouTube-Versionen Versionen nicht - also auch das 10-Mbit-VBR-Original, das ich hochgeladen hatte, sah noch um Längen besser aus als die YouTube-Version, die aus meinem 50-Mbit-Upload entstanden ist.

[dienstag_01]

Hallo Beiti, ohne die Videos gesehen zu haben, ich glaube, niemand behauptet, dass 50mbit nicht besser als 10 aussehen (können).
10mbit sind eben einfach zu wenig, selbst Premiere hat als Standard 16mbit.
Damit solltest du das mal probieren ;)

[beiti]

Hallo Beiti, ohne die Videos gesehen zu haben, ich glaube, niemand behauptet, dass 50mbit nicht besser als 10 aussehen (können).

Ja, aber darum geht es gar nicht. Es geht darum, dass ein Upload in 50 MBit gegenüber 10 MBit noch eine kleine Verbesserung bewirkt, obwohl das fertige YouTube-Video dann in jedem Fall weit unter 10 MBit/s hat. Also dass man quasi mit einem Daten-Overkill den YouTube-Encoder ein bisschen milder stimmen kann.

Wie gesagt: Mit diesem speziellen Ausgangsmaterial sehen beide YouTube-Versionen grausam schlecht aus - aber eben die aus dem 50-Mbit-Upload in gewissen Bereichen etwas weniger grausam als die aus dem 10-Mbit-Upload.

[Jörg]

starshine schreibt

Und wie gesagt, Premiere ist nicht wirklich super um h264 sauber zu codieren. Es braucht einfach mehr Fleisch dran.

zeig doch mal deine Exportsettings, da läuft was schief...

[Jott]

YT encodiert nach dem Upload nochmals auf den V9-Codec, soweit ich das bis jetzt recherchieren konnte.

YouTube encodiert jedes hochgeladene Video neu, und zwar zu einem ganzen Haufen von Formaten mit verschiedenen Auflösungen und Datenraten. Beim Abspielen wird dann auf der Basis diverser Kriterien blitzschnell entschieden, welches File gespielt wird.

[dienstag_01]

Hallo Beiti, ohne die Videos gesehen zu haben, ich glaube, niemand behauptet, dass 50mbit nicht besser als 10 aussehen (können).

Ja, aber darum geht es gar nicht. Es geht darum, dass ein Upload in 50 MBit gegenüber 10 MBit noch eine kleine Verbesserung bewirkt, obwohl das fertige YouTube-Video dann in jedem Fall weit unter 10 MBit/s hat. Also dass man quasi mit einem Daten-Overkill den YouTube-Encoder ein bisschen milder stimmen kann.

Wie gesagt: Mit diesem speziellen Ausgangsmaterial sehen beide YouTube-Versionen grausam schlecht aus - aber eben die aus dem 50-Mbit-Upload in gewissen Bereichen etwas weniger grausam als die aus dem 10-Mbit-Upload.

Und dein 10mbit File ist das originale gewesen?

[beiti]

Und dein 10mbit File ist das originale gewesen?

Nein, natürlich nicht. Das 10-MBit-File hatte durchaus schlechtere Qualität als das 50-MBit-File.

[mash_gh4]

Beim Abspielen wird dann auf der Basis diverser Kriterien blitzschnell entschieden, welches File gespielt wird.

es wird zwar ja nach verwendetem browser bzw. betriebssystem entschieden, welche grundsätzlichen codecs oder adaptiven auslieferungsmechanismen verwendet werden, aber im wesentlichen kommt praktisch immer HLS od. DASH zur anwendung. das bedeutet, dass nicht einfach nur eine einzige fertig vorbereite variante ausgeliefert wird, sondern quasi eine ganze liste übergeben wird, und je nach tatsächlich verfügbarer übertragungsbandbreite zum betrachter möglichst optimale fragmente genutzt bzw. heruntergeladen werden. wenn die bandbreite nicht reicht od. erkennbar reserven bietet, wird dann on the fly während der übertragung auf andere angebotene varianten gewechselt.

siehe: https://en.wikipedia.org/wiki/Adaptive_ ... _streaming

das ganze funktioniert im grunde ziemlich einfach über ganz normale web- bzw. http-server, weshalb man es durchaus auch selber in gleicher weise ohne großartigen technischen aufwand abwickeln kann, wenn man bessere qualität haben will als es die großen anbieter mit rücksicht auf ihre anbindung- und speichervolumenskosten erlauben.

[dienstag_01]

Und dein 10mbit File ist das originale gewesen?

Nein, natürlich nicht. Das 10-MBit-File hatte durchaus schlechtere Qualität als das 50-MBit-File.

Naja, da erübrigt sich doch jeder Kommentar.

[prime]

Eine meiner Versuche steht zufällig noch bei YouTube.
(...)
Ich habe den Clip zum Vergleich einmal mit 10 MBit und einmal mit 50 MBit hochgeladen.
Beide YouTube-Versionen sind voll von Flächen-Artefakten. Aber zum Beispiel die Bäume am Rand und auch der Wald im Hintergrund sind in der 50-Mbit-Version zumindest etwas besser als in der 10-Mbit-Version.
Schön sind beide YouTube-Versionen Versionen nicht - also auch das 10-Mbit-VBR-Original, das ich hochgeladen hatte, sah noch um Längen besser aus als die YouTube-Version, die aus meinem 50-Mbit-Upload entstanden ist.

Ich hab mal beide Versionen in der FullHD Variante runtergeladen, mit ffmpeg Screenshots bei 0, 5, 10, 15 und 20s erstellt und nebeneinander verglichen.. für mich kein Unterschied zu Gunsten der 50MBit Variante.
Beide Videodateien sind nahezu gleich groß:

10Mbps Variante: 10408639 bytes
50Mbps Variante: 10412877 bytes

Die 10Mbps sieht bei t0 sogar ein Tacken besser aus.. aber nichts erhebliches.

[beiti]

Ich hab mal beide Versionen in der FullHD Variante runtergeladen, mit ffmpeg Screenshots bei 0, 5, 10, 15 und 20s erstellt und nebeneinander verglichen.. für mich kein Unterschied zu Gunsten der 50MBit Variante.

Ich gebe zu, es sind nicht die besten Beispiele - auch weil die verwendete Actioncam sehr weiche Bilder liefert und man daher wenig Feinheiten zum Vergleich hat. Die anderen Beispiele habe ich leider nicht mehr; da müsste ich erst nochmal was Geeignetes hochladen.

Das Ganze entstand übrigens im Rahmen eines oder mehrerer Threads im VAD-Forum. Am Anfang war ich auch noch der Überzeugung, dass eine hohe Upload-Rate für YouTube nichts bringt. Inzwischen habe ich aber einige Beispiele gesehen, die mich vom Gegenteil überzeugt haben. Im Speziellen gilt das bei Verwendung des Encoders in Edius, der in Bezug auf bewegte Bildinhalte offenbar völlig anders arbeitet und andere Schwerpunkte setzt als der YouTube-Encoder (was dann zu einer "Addition" der Fehler beider Encoder führt). Inwieweit das bei anderen Schnittprogrammen/Encodern ähnlich ist, müsste man noch separat untersuchen.

[TomStg]

starshine schreibt

Und wie gesagt, Premiere ist nicht wirklich super um h264 sauber zu codieren. Es braucht einfach mehr Fleisch dran.

zeig doch mal deine Exportsettings, da läuft was schief...

Und dabei neben der Bitrate auch den Keyframe-Abstand im Auge haben. Fällt in dieser Diskussion bisher völlig unter den Tisch.

[prime]

Das Ganze entstand übrigens im Rahmen eines oder mehrerer Threads im VAD-Forum. Am Anfang war ich auch noch der Überzeugung, dass eine hohe Upload-Rate für YouTube nichts bringt. Inzwischen habe ich aber einige Beispiele gesehen, die mich vom Gegenteil überzeugt haben. Im Speziellen gilt das bei Verwendung des Encoders in Edius, der in Bezug auf bewegte Bildinhalte offenbar völlig anders arbeitet und andere Schwerpunkte setzt als der YouTube-Encoder (was dann zu einer "Addition" der Fehler beider Encoder führt). Inwieweit das bei anderen Schnittprogrammen/Encodern ähnlich ist, müsste man noch separat untersuchen.

Bin nicht davon überzeugt.. aber das muss ja nix heissen ;-)

Ist eigentlich sehr leicht überprüfbar:
- die verschiedenen Varianten hochladen
- den YouTube Encoder seine Arbeit machen lassen
- wieder runterladen und vergleichen

Ich bin der Meinung das bei einer ausreichenden Bitrate die Addition der Encoder-Fehler in der "ersten Generation" nahezu unsichtbar ist (Ausnahmen vorbehalten.. z.B. sehr niedrige Bitrate etc.).

Und dabei neben der Bitrate auch den Keyframe-Abstand im Auge haben. Fällt in dieser Diskussion bisher völlig unter den Tisch.

In diesen konkreten Vergleich sind die Keyframes an identischen Positionen und nehmen sich nicht viel in Hinsicht auf Bildqualität. Die Bitrate ist auch nahezu identisch.

[robbie]

Mit welcher Datenrate nimmt die Actioncam denn auf?
Es ist alles sinnlos wenn ich 50Mbit hochlade, das ich vorher aus einer 20Mbit-Datei hochgerechnet habe.

Ausgangsmaterial in 4:2:2 (nativ) oder gar RAW macht für solch einen Test durchaus Sinn. Mal schauen wie viel Zeit ich heute habe, aber ich geh das jetzt dann mal an.

[beiti]

Ausgangsmaterial in 4:2:2 (nativ) oder gar RAW macht für solch einen Test durchaus Sinn. Mal schauen wie viel Zeit ich heute habe, aber ich geh das jetzt dann mal an.

Würde mich auch interessieren, was da rauskommt. Wenn das Wetter mitmacht, werde ich demnächst auch nochmal eigene Versuche starten - insbesondere im Hinblick auf VP9. Als ich meine letzten Tests gemacht habe, hat YouTube ja noch standardmäßig H.264 ausgeliefert.

Die Frage ist, mit welcher Art von Material man es am besten probiert. Klar ist, dass die Aufnahmen viel Bewegung enthalten sollen. Damals hat man mir zu Fahraufnahmen geraten, weil die für den YouTube-Encoder wohl am meisten Schwierigkeiten mit sich brachten (permanente perspektivische Änderung). Inwieweit das jetzt auch noch für VP9 gilt, wäre rauszufinden.
Die andere Frage ist, welche Belichtungszeit man wählen sollte: Lieber lange Belichtung und viel Bewegungsunschärfe oder kurze Belichtung und knackscharfe Einzelbilder? Ich tendiere zu Letzterem, weil ich glaube, dass man Flächen-Artefakte daran besser erkennt.

[mash_gh4]

Ausgangsmaterial in 4:2:2 (nativ) oder gar RAW macht für solch einen Test durchaus Sinn. Mal schauen wie viel Zeit ich heute habe, aber ich geh das jetzt dann mal an.

Würde mich auch interessieren, was da rauskommt.

auf mich klingt das schon ein bisserl so, als würde man das rad ständig wieder neu erfinden müssen. immerhin gibt es wirklich sehr viele derartige tests, die man ohnehin nur zu lesen braucht.

Die Frage ist, mit welcher Art von Material man es am besten probiert. Klar ist, dass die Aufnahmen viel Bewegung enthalten sollen.

am besten nimmt man eine der bekannten freien testszene, die für genau solche tests vorgesehen sind, damit man die ergebnisse auch mit anderen messreihen und publikationen vergleichen kann:

bspw.: "crowd_run", "pedestrian_area" od. "ducks_take_off"

https://media.xiph.org/video/derf/

[dienstag_01]

Film doch einfach etwas, wo man hinterher auf YT auch noch erkennen kann, was es ist ;)

Ich glaube, jedem sollte klar sein, dass die Bitrate des Materials nur eine von mehreren Stellschrauben ist. Ab einer bestimmten Größe bringt eine Erhöhung gar nichts mehr an Qualität. Und diese Größe liegt nicht oberhalb der Bitrate des Ausgangsmaterials, sondern darunter. Ich rede hier von h264, nur zum Verständnis.
Aus dem, was man hier größtenteils liest, spricht eigentlich nur Hilflosigkeit, bis dahin, dass manche (Filmfirmen) angeblich mehr Datenrate haben müssen.
Die haben einfach Ahnung.

[prime]

auf mich klingt das schon ein bisserl so, als würde man das rad ständig wieder neu erfinden müssen. immerhin gibt es wirklich sehr viele derartige tests, die man ohnehin nur zu lesen braucht.

Die Frage ist, mit welcher Art von Material man es am besten probiert. Klar ist, dass die Aufnahmen viel Bewegung enthalten sollen.

am besten nimmt man eine der bekannten freien testszene, die für genau solche tests vorgesehen sind, damit man die ergebnisse auch mit anderen messreihen und publikationen vergleichen kann:

bspw.: "crowd_run", "pedestrian_area" od. "ducks_take_off"

https://media.xiph.org/video/derf/

Aus Spass.. hab meinen quick & dirty test mit der crowd_run Sequenz wiederholt.

Encoding:

Code: Alles auswählen

ffmpeg -i crowd_run_1080p50.y4m -c:v libx264 -crf:v 8 crowd_run_x264_crf8.mp4
ffmpeg -i crowd_run_1080p50.y4m -c:v libx264 -crf:v 20 crowd_run_x264_crf20.mp4
ffmpeg -i crowd_run_1080p50.y4m -c:v libx264 -crf:v 30 crowd_run_x264_crf30.mp4

Resultierende Dateigrößen:

Code: Alles auswählen

crowd_run_x264_crf8.mp4  340278503 bytes (325 MB)
crowd_run_x264_crf20.mp4  47445278 bytes (45 MB)
crowd_run_x264_crf30.mp4  11649680 bytes (11 MB)

Alle separat auf YT hochgeladen, gewartet und wieder runtergeladen.
Das Ergebnis wird euch überraschen ;-P

Dateigröße von YouTube Dateien:

Code: Alles auswählen

crowd_run_x264_crf8_YT.mp4   6367643 bytes (6.1 MB)
crowd_run_x264_crf20_YT.mp4  6368909 bytes (6.1 MB)
crowd_run_x264_crf30_YT.mp4  6360439 bytes (6.1 MB)

Bildqualität ist nahezu identisch. Artefakte mal hier mehr, mal dort. Für die Leute, die etwas von PSNR/SSIM halten, hier die Werte:

Original H264 vs Original vor dem Upload:

Code: Alles auswählen

crowd_run_x264_crf8.mp4
SSIM Y:0.992527 (21.264765) U:0.985257 (18.314111) V:0.983452 (17.812587) All:0.989803 (19.915082)
PSNR y:44.634515 u:45.779093 v:45.693137 average:44.971534 min:43.704315 max:50.692198

crowd_run_x264_crf20.mp4
SSIM Y:0.941520 (12.329940) U:0.912727 (10.591192) V:0.919654 (10.950382) All:0.933077 (11.744248)
PSNR y:35.169577 u:37.718005 v:38.356626 average:35.930090 min:34.851868 max:39.922513

crowd_run_x264_crf30.mp4
SSIM Y:0.840057 (7.960348) U:0.846222 (8.131059) V:0.863539 (8.649913) All:0.844998 (8.096632)
PSNR y:29.192576 u:34.800281 v:35.479384 average:30.432255 min:29.566001 max:33.043387

H264 von Youtube:

Code: Alles auswählen

crowd_run_x264_crf8_YT.mp4
SSIM Y:0.737104 (5.802168) U:0.808042 (7.167944) V:0.829658 (7.686772) All:0.764353 (6.277380)
PSNR y:26.452863 u:33.499086 v:34.069116 average:27.829020 min:26.991377 max:29.163846

crowd_run_x264_crf20_YT.mp4
SSIM Y:0.740198 (5.853573) U:0.803864 (7.074425) V:0.825341 (7.578084) All:0.764999 (6.289310)
PSNR y:26.490364 u:33.397949 v:33.955635 average:27.854090 min:27.114624 max:29.017725

crowd_run_x264_crf30_YT.mp4
SSIM Y:0.729036 (5.670878) U:0.793187 (6.844215) V:0.815982 (7.351395) All:0.754219 (6.094509)
PSNR y:26.230135 u:33.082394 v:33.633327 average:27.588717 min:26.925014 max:28.741988

Schön zu sehen, das crf8 und 20 nach YouTube in etwa auf dem Level von crf30 sind, trotz der massiv unterschiedlichen Bitraten.

Von daher - kann mash_gh4 und dienstag_01 nur zustimmen.

[beiti]

Mir ist inzwischen klar geworden, dass die Diskussion um die Höhe der Bitrate relativ sinnlos ist, wenn man nicht auch verschiedene Encoder vergleicht und natürlich den Bildinhalt berücksichtigt (Menge von Details und Bewegung im Bild). Also eine pauschale Aussage wie "Wenn YouTube das sowieso auf 6 MBit/s runterkomprimiert, reicht ein Upload mit 8 MBit/s locker" funktioniert nicht.

Meine YouTube-Versuchsreihen vor ein paar Jahren hatten ausschließlich den Edius-Encoder mit Hardwareunterstützung (QuickSync) zur Grundlage, weil der halt rasend schnell arbeitet und insofern sehr praktisch ist. Damals habe ich nicht groß darüber nachgedacht. Aber nur weil der Edius-Encorder z. B. mit 8 MBit/s deutlich mehr Fehler produziert als bei 30 oder 50 MBit/s, muss das ja nicht auch auf andere Encoder zutreffen.
Vor geraumer Zeit habe ich mal in anderem Zusammenhang den Edius-Encoder mit/ohne QuickSync sowie Handbrake mit X.264 vergleichen. Da zeigte sich, dass bei niedrigeren Bitraten Edius mit Software-Codierung die schlechtesten Ergebnisse liefert. Edius mit Quicksync arbeitet überraschenderweise besser (und dazu auch noch viel schneller). Jedoch die VBR-2Pass-Codierung mit X.264 war beiden Edius-Varianten haushoch überlegen (allerdings auch sehr langsam - noch viel langsamer als der Edius-Software-Encoder).

Wenn ich diese Erkenntnisse jetzt zusammenbringe, wundert mich auch nicht mehr, dass "prime" zwischen den mit X.264 codierten Varianten so gut wie keinen Unterschied feststellen konnte. Denn wenn die Varianten schon bei direkter Betrachtung kaum Artefakte zeigen, ist ja auch nichts da, was sich zu den YouTube-Artefakten addieren könnte.

Könnte das die Lösung des Rätsels sein?
Dann müsste die Empfehlung lauten: Man sollte Uploads für YouTube so codieren, dass man auch bei kritischer Analyse möglichst keine Artefakte mehr sehen kann. Ob dafür dann 4 oder 8 oder 16 oder 50 MBit/s nötig sind, kann man vorher nicht pauschal sagen, weil es vom verwendeten Encoder und dessen Einstellung sowie vom Bildinhalt abhängt.

[prime]

Könnte das die Lösung des Rätsels sein?
Dann müsste die Empfehlung lauten: Man sollte Uploads für YouTube so codieren, dass man auch bei kritischer Analyse möglichst keine Artefakte mehr sehen kann. Ob dafür dann 4 oder 8 oder 16 oder 50 MBit/s nötig sind, kann man vorher nicht pauschal sagen, weil es vom verwendeten Encoder und dessen Einstellung sowie vom Bildinhalt abhängt.

Jackpot!
So ist es. HW-Encoder oder die zahlreichen Encoder von verschiedenen Programmen sind oft nicht so toll wie x264. Upload zu YT sollte eben so gut wie möglich sein, unnötiges aufblasen hilft nicht.

[beiti]

unnötiges aufblasen hilft nicht.

Wobei eine höhere Bitrate nicht immer ein unnötiges Aufblasen darstellt, wenn der Encoder des Schnittprogramms sclecht ist. Also wenn meine Kamera z. B. 25 MBit/s aufgenommen hat und ich schneide das mit einem Schnittprogramm, dessen Encoder nicht so toll ist, können 50 MBit/s durchaus sinnvoll sein zum Erhalt der Qualität.

[blueplanet]

...wobei wir bei der "Gretchenfrage" wären: welches Schnittprogramm beinhaltet den besten .h264 Encoder?
Ich denke, dass Adobe Premiere, als eines der renomiertesten Videoprogramme "für den Hausgebrauch", nicht schlecht abschneidet...und das ganz unabhängig auf welcher Betriebssystembasis.