ich versuche gerade einen neuen Kurzfilm in möglichst guter Qualität für einen YouTube-Upload rauszurendern, treffe dabei jedoch auf ein seltsames Phänomen.
Ich habe Canon 550D Footage ganz schön durch die Mangel genommen im Grading und Banding mit leichtem Grain bekämpft. Das sieht in der Premiere-Vorschau für meine Bedürfnisse auch vollkommen okay aus.
Nun habe ich das Video in 14 Mbps VBR H.264 ausgegeben (1 GB für 10 Minuten), was immerhin qualitativ gut genug ist, dass man das Grain in nahezu allen Einstellungen deutlich sieht und keine Kompressionsartefakte auftreten - bis auf einige wenige Einstellungen, wo ein schwarz gekleideter Herr zu sehen ist. Hier gibt es plötzlich RIESIGE Blockartefakte. Wie kann das sein?
Bild im Anhang.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Evtl. mit konstanter Bitrate (CBR) rendern statt mit 'VBR' (variable bit rate), damit die Bitrate an solchen grossflächigen Motiven ohne Details nicht automatisch zu tief eingestellt wird.
Du schreibst, 1 GB für 10 Minuten, was einer totalen Bitrate (Bild und Ton) von 1024*8 Mbit/(10*60) Sec = 13.65 Mbps entspricht, also ziemlich genau den 14, die Du als VBR eingestellt hast.
Nachteil von CBR: Bei schnellen Bewegungen hast Du keine Bit-Reserven nach oben.
Du hast einen (oder mehrere) "Round-Trip" da drin.
Schau Dir mal das Histogramm an. Das, was Du da als "Lücken" drin siehst, wird in der 8 Bit Version indexiert. Ergebnis sind die zugeordneten Lumawerte zu den einzelnen Makroblöcken.
Das wäre so meine erste Diagnose, ohne das Originalmaterial zu kennen.
Man müsste als nächstes das 8Bit Originalbild sehen, weil der Premiere-Output irrelevant ist und ge-dithert sein kann.
Zur Probe kannst Du das auch mal als 10Bit Version ausspielen, ob es dann so aussieht wie das Premiere Bild.
was würde das ausspielen als 10bit bringen? bei 8 bit ausgangsmaterial ist doch genau keine steigerung zu erwarten und es können auch keine neuen "reserven" entstehen da die möglichkeiten des weiteren farbraums gar nicht angesprochen werden, da keine zuordnung bzw bewusstsein von der engine für sie besteht und so kein anspruch auf sie erhoben wird.
ist nicht einfach nach grading irgendwann schluss, da nur x werte der farbe für diesen bereich hinterlegt sind, welche durch die kompression evtl. verstärkt werden?
Wenn Du von 8 Bit kommst und in 10 Bit arbeitest, werden alle fehlenden Werte (und das sind die meisten) mit einer Pixelstruktur aufgefüllt. Dafür gibt es unterschiedliche Algorithmen.
Du arbeitest also in 10 Bit mit 8 Bit echten Informationen und 2 Bit animierten Informationen.
Wenn Du also in 10 Bit ausspielst spielst Du immer das "Gemisch" aus und das Auge kann relativ schwer zwischen dem "echt" und "unecht" unterscheiden.
Gehst Du jetzt aber zurück auf 8 Bit, muss unterschieden werden weil einfach zuviel Werte da sind.
Nun sind die Übergänge aber nicht so klar, weil die Rechenfehler sie bereits verändert haben. Also werden die Werte entlang einem Index zugeordnet.
"bisschen mehr" könnte schon der andere Wert sein und damit hast Du einen relativ groben Übergang.
Das ist ja der Vorteil, von H264. Die IDCT erzeugt keine Rechenfehler mehr, sodass die Werte nach der Bearbeitung wieder exakt da landen, wo sie waren (wenn Du in 8Bit IDCT bleibst). Sonst handelst Du Dir sowas ein.
gut. demnach interpoliert eine 10bit verarbeitung bei 8 bit material werte. das habe ich mir auch maximal gedacht. vor jahren habe ich einmal genau deshalb gefragt, und zwar ob man sich so reserven schaffen könnte. wenn ich zb einen 8bit verlauf irgendwie in 10bit "grade", ob dann vllt durch die neuberechnung etwas smootheres bei rauskommen kann, da in der 10bit versin ja theorietisch 4096 farbwerte pro kanal statt 256 verwendet würden. ob das nur zu "grütze" führt oder ob ich damit material etwas aufwerten kann (vovon ich ausgehe, das es aufgrund der interpolierung und der 8bit grundlage eher schiefgeht)
Du kannst 8Bit Material mit einem 10 Bit Roundtrip nur verschlechtern !!
Je nachdem, welche Ditheringalgorithmen angewandt werden, kann das sogar zu deutlichem Banding führen.
Ich denke der schlüssigste (und eigentlich offensichtlichste) Weg ist es für mich tatsächlich einfach CBR zu nutzen, damit in dem Fall kein Abfall der Informationen im Schwarzen passieren. Ist natürlich logisch, da ist ja wirklich nicht viel Information, dennoch stört das extreme "Verblocken" in dem Bereich sehr.
Wenn die Blockbildung im Originalbild nicht ist, nutzt Dir auch die Veränderung der Datenrate nichts. Aber mach mal.
Ausserdem ist CBR genau die falsche Methode, weil nur eine mittlere Datenrate zugewiesen wird, wohingegen bei VBR die Energie, die dem DCT-Koeffizienten entspricht und im Fehler-Frame enthalten ist, je nach Komplexität der Details sowie der Bewegung innerhalb der Frames variiert, sich also dem Komplexheitsgrad anpasst.
Ob dass nun klappt, na Du wirst es uns dann sagen.
Eine Verbesserung hat es nicht gegeben. Eigentlich auch wieder logisch, wie du schon sagst, denn eine insgesamt höhere Bitrate gibt es dadurch natürlich auch nicht. Ich würde sagen es sieht so aus als behandelt der Encoder die schwarze Fläche halt als besonders vernachlässigbar, auch wenn im Original deutlich mehr Informationen vorhanden sind und das Grain verhandene Farbblöcke eigentlich dithern soll.
Nein, glaub es mir. Wenn der Encoder etwas vernachlässigt, dann nimmt er die Eingangswerte, also das intakte, aber unveränderte Bild an der Stelle.
Hier finden Umrechnungsprozesse statt, die vermeidbar sind.
Wir hantieren nun seit 10 Jahren mit dem 10 Bit 8 Bit Problem und solche Sachen sind hausgemacht, wenn man nur "blind" damit hantiert und das Netz ist ja voll von solchem Zeug.
Da bist Du ja nicht der Einzige, der darunter leidet. Du bist nur wenigstens sensibel genug, es überhaupt zu sehen.
Die Meisten sehen es ja noch nicht mal. :-(
Nathanjo hat geschrieben:Ich würde sagen es sieht so aus als behandelt der Encoder die schwarze Fläche halt als besonders vernachlässigbar, auch wenn im Original deutlich mehr Informationen vorhanden sind
Natürlich tut er das. Irgendwoher müssen die Einsparungen ja kommen.
Ich habe mir das Beispiel noch einmal angesehen. Die Blockbildung ist minimal und zudem noch in einem sehr dunklen Bereich. Ich finde Du jammerst auf recht hohem Niveau.
Dann macht aber eine einfarbige Fläche daraus und auch nur, wenn die Bewegungsprädiktion so hoch ist und deutlich mehr als 60% der Rechenzeit in Anspruch nimmt, dass solche Berechnungen vernachlässigt werden.
Dazu müsste sich der Mensch auf dem Bild aber gerade sehr schnell bewegen oder irgendwo herunterfallen.
Sieht aber nicht wirklich so aus.
Der Ts soll uns doch mal das Kamera-Originalbild posten dann kann man doch mal eher sehen, was da genau passiert.
Der Witz ist, WoWu, hier gibt es doch gar keinen Roundtrip, zumindest schreibt Nathanjo nichts davon, es wäre nicht der übliche Premiere-Workflow. Das sind doch typische Kompressionsartefakte nach dem 40 mbps Original (550D), die, wenn sie (noch) nicht in der 14 mbps-Datei zu sehen gewesen wären, von Youtubes eigenem Encoder auf 3,5 mbps hinzugefügt würden. Du selbst gabst mal den Tip, solche Bereiche mit Korn zu rendern. Das funktioniert.
Ich will den ganzen Thread nicht nochmal durchforsten, aber im vorgelagerten Thread hat er davon geschrieben.
Dies ist nur eine Abkopplung des Startthreads und das mit dem GRAIN hat er auch gemacht, der GRAIN Effekt ist aber ein Anderer, nämlich dann, wenn ganze Flächen nicht auflösen. Hier gibt es aber unterschiedliche Makroblöcke, die Fläche löst also auf, aber so, wie es aussieht nur gröbster Makroblockebene.
Also.. andere Baustelle.
Dann macht aber eine einfarbige Fläche daraus und auch nur, wenn die Bewegungsprädiktion so hoch ist und deutlich mehr als 60% der Rechenzeit in Anspruch nimmt, dass solche Berechnungen vernachlässigt werden.
Dazu müsste sich der Mensch auf dem Bild aber gerade sehr schnell bewegen oder irgendwo herunterfallen.
Keine Ahnung, was Du meinst. Einen Zusammenhang mit der Rechenzeit kann ich nicht herstellen.
Für mich sieht nach einem Artefakt aus, wie es Codecs in dunklen Bereichen produzieren können. Ein Bewegungsvektor aus der Nähe oder gar keiner und dafür ein leicht bewegtes Motiv (das franzt die Abgrenzungen der sonst rechteckigen Blockstruktur stärker aus) in Kombination mit einer hohen Quantisierung der Koeffizienten bei der Kompression des Residuums, um Bits zu sparen. Letzteres kann man ausprobieren, indem man ein JPEG sehr verlustbehaftet komprimiert.
Letztlich bleibt diese Ferndiagnose natürlich nur spekulativ und ist eine Vermutung.
Deswegen ja auch der Vorschlag, sich das Originalbild mal abzusehen. Aber die Erhöhung der Bitrate hat ja auch nix gebracht und wenn das original es noch gepackt hat, kann es nur ein Bearbeitungsfehler sein.
Möglich wäre es. Kann man sehr schlecht aus der Ferne beurteilen. Hast aber Recht, er sollte den originalen Clip und den stärker komprimierten Clip zeigen und nicht nur ein einzelnes Frame.
Ich bleibe aber dabei, dass er auf recht hohem Niveau jammert. :-)
Außer ihm selbst wird das vermutlich nie jemandem auffallen.
Na ja, die Ansicht teile ich nicht so ganz. Die Bauklötze hätten mich auch gestört.
Bildfehler sind Bildfehler. Mit einer guten Arbeit haben die nichts zu tun.
(Das soll jetzt keine Kritik am gezeigten Objekt sein, sondern ist grundsätzlich gemeint.)
Dass irgendwo Artefakte auftauchen und bei YouTube nach der Kompression sowieso, ist mir natürlich klar. Was mich stört ist, dass da so riesige Blöcke in einem einzelnen Bereich des Bildes auftauchen, wenn der restliche Bildbereich deutlich das von mir hinzugefügte Grain zeigt, ohne sichtbare Artefakte. Was mich stört ist nur das krasse Missverhältnis dieser beiden Bereiche.
Im Anhang nun zumindest mal das Original komplett vor jeglicher Farbkorrektur, wenn auch nur abermals ein Frame. Da sind schon deutliche Blöcke von der kameraintern Kompression zu sehen, aber noch einiges mehr an Information. Dazu das gegradete Bild (beide mit Frame-Export aus Premiere ausgegeben). Das sieht ja auch relativ furchtbar aus, ist aber durch das Grain gedithert.
Ich beginne zu glauben, dass sich da nichts tun lässt, außer vielleicht die Bitrate zu erhöhen. Aber irgendwann wird's dann schwierig mit dem Upload und das für die eh hohe Kompression von YouTube... da gebe ich mich dann wohl lieber geschlagen.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Beide Bilder sind aber nach dem Premiere import ?
Kannst Du nicht mal das Originalfile auf einen Player ziehen und ein Framegrap davon machen ?
Aus Premiere nutzt das nicht viel, weil der ganze Fileimport dazwischen liegt.
Du hast ganz schlicht die Tiefen zu weit runtergezogen, in eine Art zeichnungsloses "Superschwarz". Das Original ist frei von Blockartefakten. In der mit 32-bit-Genauigkeit errechneten Premiere-Vorschau winken auch noch keine Blöcke, aber man erkennt bereits das Clipping: Hier ist noch geraaade was, dort ein schwarzer Pechsee. Ist doch klar, dass das Blöcke gibt bei der Kompression. Mit Waveform-Monitor sicherstellen, dass das Hemd nicht komplett absäuft.
Ich werde mir das Grading nochmal ansehen, aber wie gesagt, das Grundproblem kann das alles eigentlich nicht sein. Selbst wenn die Kleidung eine komplett schwarz Fläche wäre liegt da ein deutlich sichtbarer Grain drauf, den die Kompression (wohl einfach aufgrund immernoch nicht ausreichend vorhandener Bitrate) einfach verschluckt.
Einen Clip posten werde ich nun nicht mehr, auch wenn ich dankbar dafür bin, dass WoWu da so in die Tiefe gehen will. Ich fürchte das Originalvideo wird da auch nicht viel helfen, das Problem tritt ja schließlich nach ziemlich extremem Grading auf, wo ich Artefakte erwartet und mit Grain zu bekämpfen versucht habe. Ich mache halt mit der 550D-Footage Dinge, für die sie nicht gemacht ist. Schade nur, dass die Kompression, sogar in recht hoher Qualität, meine Bemühungen soviel zu retten wie geht wieder zunichte macht...
Aber ich denke, Du tust der Kompression Unrecht. Wir arbeiten nun seit über 10 Jahren mit 10 Bit und AVC und haben so manches mal mit genau diesen Effekten zu kämpfen gehabt und in den seltensten Fällen war die Kompression der Auslöser, oft nur die Wirkung und die Ursache lag ganz woanders.
Auch Grain ist nur in einem ganz bestimmten Fall ein probates Mittel, die Kompression "eines Besseren zu überzeugen". Oft ist Grein kontraproduktiv. Es kommt also immer darauf an, mit welcher Ausgangslage man es zu tun hat. daher meine Frage nach dem Originalbild. Nur daran kann man Verfahren festlegen.
Das ist wie mit einem Patienten. Weiss man nicht, was eigentlich seine Krankheit ist, wird man ihn auch nicht heilen können.
Du solltest vielleicht auch den Lumaanteil gegenüber Chroma einwenig erhöhen. -Erklärung wäre jetzt hier zu lang- versuch's einfach mal.
Viel Erfolg.
Nathanjo hat geschrieben:Selbst wenn die Kleidung eine komplett schwarz Fläche wäre liegt da ein deutlich sichtbarer Grain drauf, den die Kompression (wohl einfach aufgrund immernoch nicht ausreichend vorhandener Bitrate) einfach verschluckt.
Ich bin kein Experte, aber ich habe mit solchen Dingen dennoch Erfahrung. Genau wie weißes Clipping ist schwarzes Clipping für den Encoder kein verwertbares Signal, es ist digitales Nichts. Die Tiefen zu "crushen" bedeutet nicht, Werte unter Null zuzulassen, es heißt eigentlich, die unteren Mitten mittels einer Kurve nahe an Null zusammenzustauchen. Das Ergebniss ein Übergang zu Schwarz, kein Loch im Bild. Mpeg4-Encoder scheinen auch zur höheren Effizienz einen Denoiser zu benutzen (in den mehrseitigen "advanced"-Presets des x264 Encoders taucht dieser zum Beispiel auf, wäre ja nicht unmöglich, dass dann der AME auch einen einschleust, der den Grain zumindest über diesen Partien wegrationalisiert).
Generell solltest du alle deine Werte im Waveform-Bereich zwischen 0 und 100 haben, also weder darüber noch darunter.
Nathanjo hat geschrieben:Ich fürchte das Originalvideo wird da auch nicht viel helfen, das Problem tritt ja schließlich nach ziemlich extremem Grading auf, wo ich Artefakte erwartet und mit Grain zu bekämpfen versucht habe. Ich mache halt mit der 550D-Footage Dinge, für die sie nicht gemacht ist.
Ein typisches Problem wäre dann eher umgekehrt zu erwarten: Du siehst im Original keine nennenswerte Zeichnung im schwarzen Hemd, spreizt die Tiefen und kriegst ein Gestöber aus hässlichem Rauschen (das vor allem bei EOS-H.264 gerne auch mal Ministeck-Muster bildet).
Mich würde ja mal interessieren, ob es überhaupt möglich ist, die Premiere-Vorschau im Export zu reproduzieren. H264 mit extrem hoher Datenrate oder anderer Codec - erstmal egal.
dienstag_01 hat geschrieben:Mich würde ja mal interessieren, ob es überhaupt möglich ist, die Premiere-Vorschau im Export zu reproduzieren. H264 mit extrem hoher Datenrate oder anderer Codec - erstmal egal.
Also ganz ehrlich, dass ich nich auf die Idee gekommen bin, ist mir peinlich.
Gesagt, getan: mit 100 Mbps statt 14 sieht man alles. Liegt einzig und allein an der Kompression. Natürlich ist das keine Lösung für meinen YouTube-Upload, aber immerhin des Rätsels Lösung.
Trotz eurer Hilfe fürchte ich an dieser Stelle nun aber wirklich mich mit dem Ergebnis zufrieden geben zu müssen. YouTube würde eh alles kaputt machen, was besser aussieht - es ging mir einzig und allein um das beste Ausgangsmaterial bevor dies geschieht.
100 Mbit/s ist aber die Holzhammer- Methode, die eben nicht für schmale WEB Veröffentlichungen funktioniert.
Es gibt Firmen, deren Geschäftsmodell es ist, extrem hochwertigen Content auf niedrigsten Datenraten zu erstellen.
Schaut man sich an, wie sie es machen, findet man aufwändige Vorfilterung, die die Bildinhalte so aufbereiten, dass ein schmaler Codec sie schadlos durchreicht.
Zumal ja dann das Originalbild mit geringer Datenrate in Ordnung gewesen sein muss, denn 100MBit/s können aus einem Vorgeblockten Bild ja auch keine Inhalte zaubern.
Den Schaden ist also offenbar in der Bearbeitung entstanden.
Man darf Ursache und Wirkung manchmal nicht verwechseln.
Ich habe die Erfahrung gemacht dass der h264 Encoder von Premiere nicht der Beste ist (mit anderen Worten einfach nur Müll ist).
Er möge für die meisten Anwendungen ausreichen, aber für höhere/genauere Ansprüche ist er viel zu schlecht.
Schon allein die Einstellmöglichkeiten des Encoders im Dialogfenster lassen sehr zu wünschen übrig. Probier mal einen Externen aus.
Ich möchte hier keine Workflow-Diskussion auslösen, aber ich hab mir angewöhnt alles uncompressed aus Premiere rauszurenden und dann mit z.B.: XMediaRecode zu codieren.
Es ist zwar eine zeitaufwendige Arbeit sich in den h264 codec einzulesen, aber dort hast du mehr Einstellmöglichkeiten:
GOP; B-Frame; Bewegungsschätzung; !Quantisierung!; Geschwindigkeit der Codierung, genaue Bitratensteuerung und vieles mehr.
Die Ergebnisse sind um einiges besser als mit dem Premiere internen encoder und das bei oft viel weniger Datenrate!
Da es sich bei dem Projekt um einen zwar recht aufwändigen, aber eben doch nur privaten Kurzfilm handelt, welcher eh von der YouTube-Kompression durchgeknetet wird, werde ich mir diese Mühe glaube ich (noch) nicht machen.
Man glaubt es ja kaum, aber ich denke ebenfalls die Masse wird auf so etwas nicht achten...
Rechtliche Notiz: Wir übernehmen keine Verantwortung für den Inhalt der Beiträge
und behalten uns das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
