Frage von GaToR-BN:Hallo freundliche Editor,
ich weiss gerade nicht mehr weiter - vielleicht habt Ihr einen Tipp für mich. Bei meinem aktuellen Projekt erscheinen merkwürdige Artefakte im gerenderten Film (nicht in der Vorschau).
Ich nutze zum ersten Mal etwas mehr Grading mit Noise-Recution und anschließender Schärfung. Die Werte habe ich "nach Gefühl" so eingestellt. Fehler?
Könnte das damit was zu tun haben?
Hier ein paar Screenshoots von den Einstellungen
stoerung-film-export.jpgstoerung-film-resolve.jpgstoerung-film-player.jpgstoerung-denoise.jpgstoerung-sharpen.jpg
Antwort von cantsin:
Dass sind typische Codec-Glitch-Blockartefakte, und daher ein Fehler.
In welchem Codec hast Du denn rausgerendert? Und tritt der Glitch in allen Medienspielern (inkl. VLC) auf?
Antwort von Bildlauf:
Ich habe die gleiche Davinci Version wie Du, aber scheinbar hast Du Windows.
Daher zeigt er mir bei Mac nicht dieses Dropdown Menü mit Best oder was da noch verborgen ist an.
Bildschirmfoto 2023-11-21 um 18.32.38.png
Ich hatte mal so Block-Artefakte bei der Sony a7IV.
bei mir hat geholfen die kb/s auf 160000 oder gar 320000 (restrict to) einzustellen beim Export. Die Dateigröße erhöht sich dadurch zwar merklich, aber ich hatte die Artefakte nicht mehr und es war alles bestens.
Bildschirmfoto 2023-11-21 um 18.36.35.png
Kannst ja mal probieren, ob es in Deinem fall auch hilft. Also bei den Glitch Sachen (die hatte ich noch nicht, aber eben andere Sachen).
Antwort von AndySeeon:
Ich kenne solche Artefakte, wenn ich in Resolve die Clip- Geschwindigkeit ändere und Resolve dann
mit optical flow Zwischenbilder einfügt. Das sieht dann genau
so aus.
Gruß, Andreas
Antwort von Frank Glencairn:
Zunächst mal Regel Nr. 1:
Niemals H264/265 aus Resolve raus rendern - der Encoder kann nix, schon gleich gar nicht über die GPU, das ist nur zum Streaming gedacht, nicht für qualitativ hochwertige Clips.
Unkomprimierten Clip raus schreiben, dann ab damit in Handbrake mit nem vernünftigen Preset.
Deutlich bessere Qualität, und das auch noch bei deutlich niedrigeren Datenraten.
Antwort von dienstag_01:
"Frank Glencairn" hat geschrieben:
Zunächst mal Regel Nr. 1:
Niemals H264/265 aus Resolve raus rendern - der Encoder kann nix, schon gleich gar nicht über die GPU, das ist nur zum Streaming gedacht, nicht für qualitativ hochwertige Clips.
Unkomprimierten Clip raus schreiben, dann ab damit in Handbrake mit nem vernünftigen Preset.
Deutlich bessere Qualität, und das auch noch bei deutlich niedrigeren Datenraten.
In diesem Fall hier kommt der Encoder von Nvidia, hat also mit Resolve nichts zu tun. Demnach darf man den auch nie - und auch nicht in anderen Systemen - nutzen ;)
Ich denke, es kommt immer darauf an, was man braucht. Ich habe gerade Material für Projektionen genau mit diesen Encoder-Einstellungen ausgegeben, hat sehr gut funktioniert.
Antwort von Bildlauf:
"Frank Glencairn" hat geschrieben:
Niemals H264/265 aus Resolve raus rendern - der Encoder kann nix, schon gleich gar nicht über die GPU, das ist nur zum Streaming gedacht, nicht für qualitativ hochwertige Clips.
Kann ich überhaupt nicht so bestätigen das davinci diesbezüglich crap ist. Gerenderte Produkte sehen genauso gut aus wie im Schnittfenster von Davinci.
Wenn man hohe kb/s Zahlen wählt (ich nehme generell 160000, manchmal 320000) sieht es auch bei Youtube super aus.
Bin insbesondere sehr zufrieden wie YouTube die gerenderten Dateien komprimiert und insgesamt mit den Exportergebnissen. Das 4 k bei YT sieht schick aus.
Vielleicht exportiert davinci nur bei windows unzureichend, bei Mac aber gut?
Frage ist was ist das basismaterial, Longgop oder raw. Vielleicht kann der Encoder LongGop zu besseren Ergebnisse rendern, Du filmst ja immer raw, ich ja hingegen LongGop.
Hatte bei davinic nur zweimal ein renderproblem eben mit der a7IV, da gab es Blockpixelbildung. Konnte ich aber in den Exporteinstellungen beheben.
Mit der S5II gab es nie Probleme.
Nachteil, das stimmt, die Dateien sind womöglich etwas größer.
Antwort von Frank Glencairn:
Die Messergebnisse sind da eigentlich eindeutig.
https://iopscience.iop.org/article/10.1 ... 012036/pdf
https://www.compression.ru/video/codec_ ... ex_en.html
Antwort von Bildlauf:
Ich vertraue da echt auf das was ich wahrnehme und ich denke das hängt irgendwie mit anderen Dingen zusammen, Frage der Codec Wahl, Mac oder Windows, Grafikkarte oder weiß der teufel, ich bin da kein Experte. wahrscheinlich sind das individuelle Sachen, warum es bei einem gut ist und beim anderen nicht.
Ich habe da nichts zu beklagen beim Export über Davinci.
Antwort von MK:
Bildlauf hat geschrieben:
Ich habe da nichts zu beklagen beim Export über Davinci.
Es geht hier um das Encoding per GPU. Mit Davinci hat das nichts mehr zu tun wenn man das benutzt.
Zum Thema: Export mal ohne GPU-Beschleunigung des Encodings testen, treten dort die Fehler auch auf den Arbeitsspeicher des Rechners mit Memtest86+ prüfen falls das System keinen ECC-Speicher hat, und Export auf ein anderes Laufwerk testen um Hardwareprobleme auszuschließen.
Antwort von dienstag_01:
Es besteht überhaupt kein Zweifel, dass es bessere Encoder als den Nvidia-Encoder gibt. Allerdings sollte jedem klar sein, dass die wirklich relevanten Unterschiede nur bei sehr kleinen Datenraten bzw. auf Geschwindigkeit ausgelegten Profilen auftreten.
Antwort von dienstag_01:
MK hat geschrieben:
Bildlauf hat geschrieben:
Ich habe da nichts zu beklagen beim Export über Davinci.
Es geht hier um das Encoding per GPU. Mit Davinci hat das nichts mehr zu tun wenn man das benutzt.
Zum Thema: Export mal ohne GPU-Beschleunigung des Encodings testen, treten dort die Fehler auch auf den Arbeitsspeicher des Rechners mit Memtest86+ prüfen falls das System keinen ECC-Speicher hat, und Export auf ein anderes Laufwerk testen um Hardwareprobleme auszuschließen.
Hardwareproblem halte ich auch für möglich. Daher vielleicht auch einfach mal eine Softwareencoder in Davinci nutzen.
Antwort von Bildlauf:
@MK
Ja, aber es findet doch in Davinci statt, oder?
So hatte ich den Threadstarter verstanden, und ich exportiere auch raus aus davinci.
Mit GPU mache ich gar nichts, es funktioniert halt einfach, warum weiß ich auch nicht und ist doch auch gut so.
Bei Mac ist ja immer alles automatisch gut eingestellt und kooperiert generell mit Software entsprechend produktiv.
Wer ist denn schuld, die GPU oder Davinci oder der Computer oder doch der Mensch?
Antwort von MK:
Bildlauf hat geschrieben:
@MK
Ja, aber es findet doch in Davinci statt, oder?
So hatte ich den Threadstarter verstanden, und ich exportiere auch raus aus davinci.
Bei GPU-Encoding übergibt Resolve nur den unkomprimierten Datenstrom und Parameter an die GPU. NVENC ist auf der GPU fest verdrahtet und keine Beschleunigung wie CUDA welche beliebigen Code ausführen kann.
Antwort von Bildlauf:
ok, wenn man keine Ahnung hat sollte man seine Klappe halten, damit meine ich mich ;-)
Wahrscheinlich ist das eine Diskussion für Windows User oder Export-Spezialisten.
Denn viele Begriffe sagen mir was, aber die Zusammenhänge sind mir doch unklar.
Ich muss da nichts machen mit Nvidia und GPU oder CUDA etc.
Ich rendere einfach über Davinci.
Dennoch würde ich das mit der hohen kb/s - Rate wie vorgeschlagen zumindest mal versuchen, weil es bei mir mal geklappt hat, als ich zwei Fälle von Artefakten hatte in 2/3 Clips in zwei verschiedenen Projekten und diese bei höheren bzw. hohen kb/s nicht auftraten.
Antwort von cantsin:
MK hat geschrieben:
Zum Thema: Export mal ohne GPU-Beschleunigung des Encodings testen, treten dort die Fehler auch auf den Arbeitsspeicher des Rechners mit Memtest86+ prüfen falls das System keinen ECC-Speicher hat, und Export auf ein anderes Laufwerk testen um Hardwareprobleme auszuschließen.
Auch meine Empfehlung, denn das sind ganz klare Bugs/Glitches, die bei einem Hardware-basierten Encoder eigentlich nicht passieren dürften - es sei denn (@Bildlauf), Dein Rechner bzw. Deine Grafikkarte überhitzt, Du hast defekten RAM oder defekte Festplatten/SSDs.
Ansonsten: Rausrendern als ProRes oder DNxHR und mit Handbrake oder Shutter Encoder nach h264/h265 transkodieren. Dann erzielt man sowieso eine bessere Bildqualität bei gleicher Bitrate ggü. Nvenc bzw. dem Direktexport nach h264/h265 aus Resolve (erkauft sich das aber mit deutlich längeren Encodingzeiten).
Antwort von Frank Glencairn:
cantsin hat geschrieben:
Ansonsten: Rausrendern als ProRes oder DNxHR und mit Handbrake oder Shutter Encoder nach h264/h265 transkodieren.
Und wenn du dann noch statt des minderwertigen und umständlichen ProRes/DNX einfach unkomprimiert raus renderst, bevor es in Handbrake/Shutter geht, sind wir der Lösung schon näher.
Antwort von Darth Schneider:
@Frank
Wenn man jetzt zum Beispiel mit BRaw Q1/Q3, oder mit ProRes HQ aufnimmt, was wäre denn das Ideale Master Format zum raus rendern von Resolve um in Hanbrake dann h264 Delivery daraus zu machen ?
Unkompremiert wäre ja das denn nur wenn ich das ProRes HQ in ProRes HQ als Master raus rendern würde, und das BRaw ?
Keine Ahnung..;))
Gruss Boris
Antwort von Frank Glencairn:
"Darth Schneider" hat geschrieben:
Unkompremiert wäre ja das denn nur wenn ich das ProRes HQ in ProRes HQ als Master raus rendern würde, und das BRaw ?
Nein, so funktioniert das nicht.
In dem Moment wo das Material auf der Timeline liegt ist es ja kein Prores mehr, sondern von Resolve bereits "entpackt und entkomprimiert" - und jede Änderung bedeutet natürlich ebenfalls eine komplette Neuberchnung.
Das heißt also, selbst wenn du wieder ProRes raus rechnest hast du immer einen Generationenverlust.
Das gilt natürlich für alle Codecs.
Master rechne ich deshalb grundsätzlich unkomprimiert - warum auch nicht?
Ich sehe kleinen Grund, nicht die bestmögliche Qualität zu nehmen.
Antwort von cantsin:
"Frank Glencairn" hat geschrieben:
Und wenn du dann noch statt des minderwertigen und umständlichen ProRes/DNX einfach unkomprimiert raus renderst, bevor es in Handbrake/Shutter geht, sind wir der Lösung schon näher.
Ich sehe da keine sichtbaren Vorteile bzw. Qualitätsunterschiede, wenn man anschließend in h264/5 mit für Hardware-Medienplayer tauglichen Bitraten komprimiert.
Außerdem sind alle unkomprimierten Formate (zumindest in Resolve) auf 10bit 4:2:2 begrenzt. Wenn ich Raw in der Timeline habe, rendere ich lieber 12bit DNxHR raus (als Master bzw. Material, das ich später ggfs. in anderen Schnittprojekten wiederverwenden kann).
Außerdem taugt unkomprimiertes Material wegen seiner Dateigrößen nicht zur Archivierung.
Antwort von freezer:
"Frank Glencairn" hat geschrieben:
Die Messergebnisse sind da eigentlich eindeutig.
https://iopscience.iop.org/article/10.1 ... 012036/pdf
https://www.compression.ru/video/codec_ ... ex_en.html
Aber nur, wenn man Deinen Links nicht folgt.
Im ersten PDF werden OpenSource encoder getestet, weder Hardware Encoder noch Resolve kommt darin vor.
Beim zweiten Link habe ich lange gesucht um Ergebnisse zu finden, ich finde sie aber nicht.
Hast Du einen direkten Link zu den eindeutigen Messergebnissen?
Antwort von Frank Glencairn:
cantsin hat geschrieben:
Außerdem taugt unkomprimiertes Material wegen seiner Dateigrößen nicht zur Archivierung.
Das eine Frage des Budgets, aber unabhängig davon so ein Intermediate File ist ja auch nur dazu gedacht, ein hochqualitatives Master für die Delivery Generierung herzustellen. Wird ja danach sofort wieder gelöscht.
Master werden bei uns allerdings sowieso nicht archiviert, sondern nur die Projekt-Consolidates - braucht weniger Platz und ist deutlich schneller, flexibler und weniger umständlich, wenn man mal was ändern muß.
Antwort von Frank Glencairn:
freezer hat geschrieben:
Aber nur, wenn man Deinen Links nicht folgt.
Im ersten PDF werden OpenSource encoder getestet, weder Hardware Encoder noch Resolve kommt darin vor.
Es ging um den Unterschied zwischen H264 (vor allem auch auf Hardware die eigentlich für schnelles Games Streaming entwickelt und optimiert wurde) und X264 - und nein Resolve kommt da nicht vor.
Antwort von cantsin:
"Frank Glencairn" hat geschrieben:
Es ging um den Unterschied zwischen H264 (vor allem auch auf Hardware die eigentlich für schnelles Games Streaming entwickelt und optimiert wurde) und X264 - und nein Resolve kommt da nicht vor.
Du verwechselt da etwas. H264 ist kein Codec, sondern ein Encodierungs-/Kompressionsstandard. x264 ist ein h264-konformer Codec.
Antwort von freezer:
"Frank Glencairn" hat geschrieben:
freezer hat geschrieben:
Aber nur, wenn man Deinen Links nicht folgt.
Im ersten PDF werden OpenSource encoder getestet, weder Hardware Encoder noch Resolve kommt darin vor.
Es ging um den Unterschied zwischen H264 (vor allem auch auf Hardware die eigentlich für schnelles Games Streaming entwickelt und optimiert wurde) und X264 - und nein Resolve kommt da nicht vor.
Dann solltest das PDF nochmals genauer lesen. Auf Seite 7 bei den PSNR Ergebnissen für 720p schneiden alle h264 Encoder gleich oder besser ab als x264.
Antwort von Darth Schneider:
@freezer
Verstehe ich das richtig ?
Dann braucht man Handbreak gar nicht zwingend für h264 auszurendern, mit Resolve geht das auch schön ?
Also ich merke ja eh keinen sichtbaren Unterschied, ob ich erst ein ProRes 4444 Master mache und über die Handbremse gehe, oder ob ich nur Resolve zum direkt h264 rendern benutze.
Aber womöglich hab ich nicht das Auge dafür. ;)
Gruss Boris
Antwort von Asjaman:
GaToR-BN hat geschrieben:
ich weiss gerade nicht mehr weiter - vielleicht habt Ihr einen Tipp für mich. Bei meinem aktuellen Projekt erscheinen merkwürdige Artefakte im gerenderten Film (nicht in der Vorschau).
Ich nutze zum ersten Mal etwas mehr Grading mit Noise-Recution und anschließender Schärfung. Die Werte habe ich "nach Gefühl" so eingestellt. Fehler?
die aktuellsten NVIDIA Treiber hast du installiert?
Diese haben mir kürzlich bei ähnlichen Erscheinungen weitergeholfen.
Antwort von cantsin:
freezer hat geschrieben:
Auf Seite 7 bei den PSNR Ergebnissen für 720p schneiden alle h264 Encoder gleich oder besser ab als x264.
Was aber äußerst seltsam ist, dass die in ihren Tests "ffmpeg" gegen x264 antreten lassen. ffmpeg ist aber nur ein Wrapper, der unter der Haube (für h264-Encoding) x264 verwendet....
Antwort von Axel:
"Darth Schneider" hat geschrieben:
Also ich merke ja eh keinen sichtbaren Unterschied, ob ich erst ein ProRes 4444 Master mache und über die Handbremse gehe, oder ob ich nur Resolve zum direkt h264 rendern benutze.
Sah kürzlich einen Test zum Upload für Youtube, Blockartefakte, Grainglättung, Detail usw. Das Ergebnis war ziemlich simpel: Resolves unverändertes H.264-Master-Exportpreset gewinnt locker gegen ein riesiges ProRes-File, das per Handbrake umcodiert wurde.
Antwort von pillepalle:
Axel hat geschrieben:
Sah kürzlich einen Test zum Upload für Youtube, Blockartefakte, Grainglättung, Detail usw. Das Ergebnis war ziemlich simpel: Resolves unverändertes H.264-Master-Exportpreset gewinnt locker gegen ein riesiges ProRes-File, das per Handbrake umcodiert wurde.
H264 rules them all! :)
VG
Antwort von Bildlauf:
@DarthSchneider
Ich habe auch viel mit handbrake versucht als ich anfing mit den ganzen Videosachen, um den Export zu optimieren insbesondere hinsichtlich Youtube.
Habe da Ewigkeiten mit verbracht alles mögliche zu testen.
Davinci exportiert super bei mir, aber eben nur in Bezug auf meine Workstation, auf meine genutzten Kameracodecs und meine Exporteinstellungen.
Wenn man 1 Milliarde Prozent reinzoomt, dann sieht man, aber auch nur manchmal, minimalste Unterschiede, aber das ist nichts. Und hat auch nichts mit Artefakten oder Glich zu tun. Wirklich kaum sichtbar. Und ich bin schon eh ein empfindlicher Typ mit Artefakten, Grafikproblemen oder auch Stabi-Zuckeln in den Ecken ;-)
Und irgendwas muss ja nunmal auch komprimiert werden, bei handbrake ja auch.
deshalb am besten einfach probieren und vergleichen. Wenn das Ergebnis für Dich aussieht wie im Schnittfenster und auch bei YT schick aussieht, was soll man sich dann noch groß über theoretische Dinge Gedanken machen.....
Export dauert auch nicht lange für meine Geschmack, zwischen 1,5 und 6 Minuten für ein 3,5 Minuten Film als Beispiel, je nachdem wie alles in der Software gemacht wird, Transitions, Titel etc. Aber der handbrake Schritt fällt ja auch weg für mich.
Inwieweit der Speicherbedarf der Datei höher ist bei davinci kann ich nicht beurteilen, aber damit käme ich für meine Sachen klar.
Bei Spielfilmexporten ist es natürlich was anderes und da kann ich verstehen, wenn man nicht davinci nutzen möchte, weil es eventuell mehr Speicher braucht.
Antwort von Axel:
pillepalle hat geschrieben:
H264 rules them all! :)
VG
Nein, wohl nicht. Da ging’s ja nur darum, was den Youtube-eigenen Encoder am besten „überlebt“ (das Youtube-Preset war das schlechteste!). Bezog sich hier speziell auf ProRes (aber wozu 444?) mit Handbrake.
Antwort von dienstag_01:
Axel hat geschrieben:
pillepalle hat geschrieben:
H264 rules them all! :)
VG
Nein, wohl nicht. Da ging’s ja nur darum, was den Youtube-eigenen Encoder am besten „überlebt“ (das Youtube-Preset war das schlechteste!). Bezog sich hier speziell auf ProRes (aber wozu 444?) mit Handbrake.
Willst du eigentlich damit sagen, dass *schlechteres* Material für Youtube am Ende *besser* ist?
(Sorry, ist hier alles sowieso schon komplett abgedriftet, mit dem eigentlichen Problem haben diese Qualitätsdiskussionen nichts zu tun. Oder einfacher: der oben gezeigte Fehler hat nichts mit der Encodingqualität zu tun.)
Antwort von MK:
dienstag_01 hat geschrieben:
Willst du eigentlich damit sagen, dass *schlechteres* Material für Youtube am Ende *besser* ist?
MPEG-1 for the win! ;-)
Antwort von Darth Schneider:
@Bildlauf
Danke,
ich habe auch mit Handbreak viel herum probiert und verglichen mit dem was Resolve heraus rendert und bin zum gleichen Fazit gekommen wie du.
Gruss Boris
Antwort von Frank Glencairn:
Axel hat geschrieben:
Sah kürzlich einen Test zum Upload für Youtube, Blockartefakte, Grainglättung, Detail usw. Das Ergebnis war ziemlich simpel: Resolves unverändertes H.264-Master-Exportpreset gewinnt locker gegen ein riesiges ProRes-File, das per Handbrake umcodiert wurde.
Natürlich - die Qualität ist doch immer vom, letztendlichen Encoding in der Kette abhängig.
Wenn's nur um YT geht, brauchst du dir um sowas deshalb sowieso keinen Kopf zu machen.
Antwort von Axel:
dienstag_01 hat geschrieben:
Axel hat geschrieben:
Nein, wohl nicht. Da ging’s ja nur darum, was den Youtube-eigenen Encoder am besten „überlebt“ (das Youtube-Preset war das schlechteste!). Bezog sich hier speziell auf ProRes (aber wozu 444?) mit Handbrake.
Willst du eigentlich damit sagen, dass *schlechteres* Material für Youtube am Ende *besser* ist?
Hier ging es um Kompression bei vergleichbaren Datenraten. Das Master-Preset hat bereits viel höhere Datenraten als von Youtube empfohlen. Wahrscheinlich deswegen
heißt es „Master“. Aber auch eine weitere Erhöhung - sowohl in Resolve als auch in Handbrake - bringt keinen sichtbaren Unterschied mehr
Antwort von dienstag_01:
Axel hat geschrieben:
dienstag_01 hat geschrieben:
Willst du eigentlich damit sagen, dass *schlechteres* Material für Youtube am Ende *besser* ist?
Hier ging es um Kompression bei vergleichbaren Datenraten. Das Master-Preset hat bereits viel höhere Datenraten als von Youtube empfohlen. Wahrscheinlich deswegen heißt es „Master“. Aber auch eine weitere Erhöhung - sowohl in Resolve als auch in Handbrake - bringt keinen sichtbaren Unterschied mehr
Was sind vergleichbare Datenraten? Gleiche? Unterschiedliche?
Vielleicht solltest du mal deine Vorschlagsliste auf Youtube ausmisten ;)
Antwort von Axel:
Vielleicht solltest du ein Snickers essen?
Antwort von dienstag_01:
Axel hat geschrieben:
Vielleicht solltest du ein Snickers essen?
Gerne, reich mal rüber ;)
Antwort von Darth Schneider:
Sogar wenn ich die Datenrate in Resolve beim Export einfach auf Auto lasse sieht das h264 toll aus.;)
Gut ich zoome nicht in Standbildsr rein um zu vergleichen.
Aber ich kann mir einfach nicht vorstellen das eine Editing Software wie Reslove Studio ausgerechnet das Encoding in h264 heute nicht im Griff haben soll…
Gruss Boris
Antwort von Axel:
Vom vom Threadstarter verlinkten Preset ausgehend würde ich statt variabler lieber konstante nehmen. Hab ja wenig Einfluss darauf, wann und aus welchem Grund die Datenrate vom Encoder gedrosselt wird.
Antwort von Darth Schneider:
Klar ich doch auch, normal mache ich das immer manuell,
hab vor ein paar Tagen einfach vergessen vor dem Export von Auto auf Manuell zu umzuschalten
Aber das h264 (auf dem USB Stick, nicht auf YouTube) sieht trotzdem gut aus.
Gruss Boris
Antwort von GaToR-BN:
Axel hat geschrieben:
Vom vom Threadstarter verlinkten Preset ausgehend würde ich statt variabler lieber konstante nehmen. Hab ja wenig Einfluss darauf, wann und aus welchem Grund die Datenrate vom Encoder gedrosselt wird.
Danke für die anregenden Diskussion und Ideen zu meinem Fehler im Video. Die Fixierung auf eine feste Datenrate auf 160000 hat ein brauchbares Ergebnis erzeugt. Nur ist das File dann auch 8 x größer geworden. Gerade läuft ein 2. Durchgang wo ich nur den Encoder von Nvida auf Native umgestellt habe.
Danke auch für den Tipp mit dem Treiber. Hier gibt es einen neuen Studiotreiber, den ich gerade herunterlade.
Antwort von dienstag_01:
GaToR-BN hat geschrieben:
Axel hat geschrieben:
Vom vom Threadstarter verlinkten Preset ausgehend würde ich statt variabler lieber konstante nehmen. Hab ja wenig Einfluss darauf, wann und aus welchem Grund die Datenrate vom Encoder gedrosselt wird.
Danke für die anregenden Diskussion und Ideen zu meinem Fehler im Video. Die Fixierung auf eine feste Datenrate auf 160000 hat ein brauchbares Ergebnis erzeugt. Nur ist das File dann auch 8 x größer geworden. Gerade läuft ein 2. Durchgang wo ich nur den Encoder von Nvida auf Native umgestellt habe.
Danke auch für den Tipp mit dem Treiber. Hier gibt es einen neuen Studiotreiber, den ich gerade herunterlade.
Das sieht ganz nach einem neuen Bug aus ;)
Antwort von Bildlauf:
GaToR-BN hat geschrieben:
Die Fixierung auf eine feste Datenrate auf 160000 hat ein brauchbares Ergebnis erzeugt. Nur ist das File dann auch 8 x größer geworden.
8 mal so groß ist natürlich eine Hausnummer.
Bei UHD:
Wenn ich zb 3 Minuten Film rendere in 160000, dann ist die Datei 3 GB groß, bei 10 Minuten halt 10 GB und so weiter. das passt so zufällig, die Umrechnung.
In 80000 sind 3 Minuten 1,5 GB usw. usf.
Du könntest aber die auf 160000 gerenderte FullHD Datei vielleicht nochmal auf normales Full HD exportieren bei weniger Datenrate, denke daß die Glitsches ja quasi durch den Export mit 160000 eliminiert worden sind und dann nicht wieder erscheinen, auch wenn man weniger Datenrate nutzt. Da das ja quasi nur eine Kopie ist in geringerer Datenrate.
Falls dem Kunden die Datei zu groß ist. Vielleicht funktioniert das ja.
