Postproduktion allgemein Forum



davinci resolve 4:2:2 problem (warnung!)



Fragen rund um die Nachbearbeitung, Videoschnitt, Export, etc. (div. Software)
Antworten
sgywalka is back
Beiträge: 171

Re: davinci resolve 4:2:2 problem (warnung!)

Beitrag von sgywalka is back »

12tes IASI_GEBOT: DU SOLLST DIE 5k-RED nehmen! aaaaaaamne :)
hab ich einen Plan? na alls dann..:)



CameraRick
Beiträge: 4806

Re: davinci resolve 4:2:2 problem (warnung!)

Beitrag von CameraRick »

mash_gh4 hat geschrieben: das kann ich leider nicht bestätigen.
ich kann die farbverfälschungen auch in einem unkomprimierten 4:2:2 v210 AVI sowohl in der 8bit als auch 10bit version sehen. :(

[...]

auch in einem 8bit 4:2:2 h264 intra mit sehr hoher qualität (-qp 1) in einem mp4-container tritt es offenbar tatsächlich nicht zu tage! übrigens auch nicht, wenn man es in einen quicktime container packt
Ich darf annehmen, dass Du Deine Files mit FFMPEG erstellst? Ich kann das verlinkte h264 im DaVInci nicht öffnen, das schmeckt ihm nicht. Dein AVI wird bei mir auch bunt.

Ich habe jetzt mal XAVC und AVC-Intra auch daheim am Windows gerechnet, beide Files sehen aus wie sie sollen. DNxHR HQX im MXF Contrainer dagegen zeigt andere, spannende Buntmuster

Alles kodiert im AME.

Sollen wir die Unterhaltung eigentlich komplett ins BMD Forum verlagern? Sind ja sonst schon alle da...
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.



mash_gh4
Beiträge: 4716

Re: davinci resolve 4:2:2 problem (warnung!)

Beitrag von mash_gh4 »

CameraRick hat geschrieben:Ich darf annehmen, dass Du Deine Files mit FFMPEG erstellst?
ja. damit kann ich am einfachsten das pixelformat und die etwas ungewöhnliche bild-/videogröße sicherstellen.

ich finde es aber prima, wenn das andere auch mit ihren gewöhnten werkzeugen gegenchecken, damit sich auf diese weise nicht irgendwelche irrtümer und fehlschlüsse einstellen, die in wahrheit natürlich auch schon beim encodieren verursacht sein könnten.
CameraRick hat geschrieben:Ich kann das verlinkte h264 im DaVInci nicht öffnen, das schmeckt ihm nicht.
das wundert mich! ich hab's jetzt vorsichtshalber selber nocheinmal vom server heruntergeladen, weil ich vor lauter ausprobieren ja evtl. irgendwelche versionen mit gleichem namen verwechste haben könnte, aber mein resolve (12.5, windows) akzeptiert es anstandslos.

ich geb aber zu, dass es ein etwas ungewöhnliches h.264 file ist. ;)
wenn man im ffmpeg mit den optionen "-codec:v libx264 -intra -qp 1" komprimiert, bekommt man files, die zwar verhältnismäßig groß sind, aber eine bildqualdqualität aufweisen, die weit höher ist als bei prores od. dnxhr ausfällt. das geschieht in diesem fall nicht einfach nur durch ein beliebiges hochschrauben der datenrate, sondern orientiert sich am informationsgehalt des bilden bzw. der tatsächlich notwendigen bandbreite. derartige AVC-intra files sind aber trotzdem mit fast allen programmen kompatibel, was ja leider nicht der fall ist, wenn man die völlig verlustfrei h264 4:4:4-profil im ffmpeg nutzt. letztere sind zwar grundsätzlich im entsprechenden standard auch spezifiziert, werden aber in der praxis nur von ganz wenige anwendungen unterstützt.
CameraRick hat geschrieben:DNxHR HQX im MXF Contrainer dagegen zeigt andere, spannende Buntmuster
ich glaube, das liegt nur daran, dass du die bilder nicht in der ursprünglichen 2048x1024 größe belassen hast. dadurch zeigen sich diese abweichenden interferenzmuster. der ganze test wird aber dadurch weitestgehend ad absurdum geführt, weil es in diesem fall ja wirklich darum geht, dass die betreffenden pixel ganz genau in der vorgesehenem weise angeordnet sind.

mit dnxhr, dass ja in seinen größenvorgaben deutlich variabler als dnxhd ist, sollte sich das vermutlich auch im avid machen lassen. ich hab's deshalb bisher unterlassen, weil ffmpeg derartige encodierung zwar seit einigen wochen unterstützt, aber die standardmäßig installierte version auf meinem system (debian testing) leider ein bisserl älter ist. ist müsste es also extra installieren bzw. mein system dafür in unordnung bringen. da ich aber aus den vorhergehenden test mit dem material des "entdeckers" dieser ganzen geschichte weiß, dass sich das problem im zusammenhang dnxhr zeigt, hab ich mich erst gar nicht weiter darum bemüht.
CameraRick hat geschrieben:Sollen wir die Unterhaltung eigentlich komplett ins BMD Forum verlagern? Sind ja sonst schon alle da...
ich persönlich finde es schon nett, dass wir es ergänzend auch hier besprechen und unsere gedanken austauschen können -- es fällt ja doch deutlich leichter, wenn man sich dabei so ausdrücken kann, wie einem der schnabel gewachsen ist ;) --, aber natürlich gilt es auch den BMD entwicklern und nutzern die wesentlichsten fortschritte und empirischen einsichten zukommen zu lassen, damit man eine baldige konstruktive lösung nach kräften unterstützt.



Frank Glencairn
Beiträge: 22709

Re: davinci resolve 4:2:2 problem (warnung!)

Beitrag von Frank Glencairn »

Ich hab mein unkomprimiertes AVI - auf basis des TIFF - aus Resolve gerechnet - da gibts jedenfalls keine Artefakte, wenn ich das selbe als unkomprimiertes QT rausrechne, kommt der Regenbogen.



CameraRick
Beiträge: 4806

Re: davinci resolve 4:2:2 problem (warnung!)

Beitrag von CameraRick »

ich finde es aber prima, wenn das andere auch mit ihren gewöhnten werkzeugen gegenchecken, damit sich auf diese weise nicht irgendwelche irrtümer und fehlschlüsse einstellen, die in wahrheit natürlich auch schon beim encodieren verursacht sein könnten.
Theorie: Resolve nutzt FFMPEG, oder "Teile" davon, zum Dekodieren. Schlecht implementiert, versteht sich.
Daher treten die Artefakte mitunter bei FFMPEG Quellen auf, bei AME aber nicht.

Ergibt das Sinn?
das wundert mich! ich hab's jetzt vorsichtshalber selber nocheinmal vom server heruntergeladen, weil ich vor lauter ausprobieren ja evtl. irgendwelche versionen mit gleichem namen verwechste haben könnte, aber mein resolve (12.5, windows) akzeptiert es anstandslos.

ich geb aber zu, dass es ein etwas ungewöhnliches h.264 file ist. ;)
[...]
Resolve bleibt beim roten Ausrufezeichen, Fusion weigert sich auch. Adobe liest es ohne Probleme.
Ich habe auf dem System weder Quicktime, noch irgendein anderes Codec-Paket manuell installiert.
ich glaube, das liegt nur daran, dass du die bilder nicht in der ursprünglichen 2048x1024 größe belassen hast
[...]
mit dnxhr, dass ja in seinen größenvorgaben deutlich variabler als dnxhd ist, sollte sich das vermutlich auch im avid machen lassen.
[...]
Ha, ich hab DNxHR geschrieben aber es war in Wahrheit ein DNxHD. Hab ich Mist gebaut und mich verschaut. Ich habe nun aber auch ein DNxHR HQX (aus AME) im MXF Container gerechnet, das ergibt auch bunte Muster; aber nicht so stückelig, sondern den Streifen wie vorher die anderen.



Nach dem Forum fragte ich nur, da dort ja noch andere Leute lesen, die auch etwas mehr interessiert scheinen. Ich lade mal meine Testclips hoch und linke sie dann dort :)



mash_gh4
Beiträge: 4716

Re: davinci resolve 4:2:2 problem (warnung!)

Beitrag von mash_gh4 »

Frank Glencairn hat geschrieben:Ich hab mein unkomprimiertes AVI - auf basis des TIFF - aus Resolve gerechnet - da gibts jedenfalls keine Artefakte, wenn ich das selbe als unkomprimiertes QT rausrechne, kommt der Regenbogen.
ich werde das nachzuvollziehen versuchen.

es gibt ja einige möglichkeite, wie "unkomprimiertes" 4:2:2 in quicktime tatsächlich aussehen kann. ich hab schon im fall AVI nur an hand der beschaffenheit des tatsächlichen resolve outputs entscheiden können, mit welchen einstellungen man ähnlichses bzw. kompatibles auch mit anderen mitteln erzielen kann.

ehrlich gestanden habe ich auch ziemliche zweifel, von welcher praktischen relevanz "unkomprimiertes" 4:2:2 YUV heute noch sein sollte? wenn man wirklich unkomprimiert bzw. verlustfrei arbeiten will, wird man gegenwärtig doch sinnvollerweise gleich zu 4:4:4 RGB greifen, wie es praktisch alle besseren programme heute intern verwenden. ich halte YUV subsampling lösungen eher für ein überbleibsel aus der broadcast welt, die in wahrheit derart einschneidene veränderungen nach sich ziehen, dass man besser nicht von "uncompressed" sprechen sollte.



mash_gh4
Beiträge: 4716

Re: davinci resolve 4:2:2 problem (warnung!)

Beitrag von mash_gh4 »

CameraRick hat geschrieben: Theorie: Resolve nutzt FFMPEG, oder "Teile" davon, zum Dekodieren. Schlecht implementiert, versteht sich.
resolve nutzt definitv z.t. ffmpeg libraries. wofür genau und wie weit diese libraries auch auf dem aktuellen stand sind, lässt sich schon viel schwerer sagen.

wichtig ist aber auch der umstand, dass sie offenbar in den letzten versionen, die sich unter windows nicht mehr auf eine externe quicktime installation stützen, scheinbar nicht zu ffmpeg als ersatz gegriffen haben, sondern entsprechende windows betreibssystem-schnittstellen nutzten. das ergibt sich bspw. aus bug-reports, wonach der UHD h.264 export unter älteren windows versionen niccht mehr funktioniert etc.
CameraRick hat geschrieben:Daher treten die Artefakte mitunter bei FFMPEG Quellen auf, bei AME aber nicht.
hast du ein beispiel, wo das der fall ist?
nach meinem wissensstand hat es bisher noch keine varaiante gegeben, wo ein derartiger unterschied festzustellen ist.
CameraRick hat geschrieben:
mash_gh4 hat geschrieben:mein resolve (12.5, windows) akzeptiert es anstandslos.

ich geb aber zu, dass es ein etwas ungewöhnliches h.264 file ist. ;)
[...]
Resolve bleibt beim roten Ausrufezeichen, Fusion weigert sich auch. Adobe liest es ohne Probleme.
das könnte u.u. mit den oben beschreibenen umstellungen in 12.5.1 und 12.5.2 zu tun haben. ich hab hier noch immer 12.5 installiert, wo das noch über quicktime läuft, und das file anstandslos akzeptiert wird.

ich kann dir aber gern ein gewöhnlicheres h.264 file generieren, nur ist es halt bei long GOP materal immer ein bisserl problematisch, wirklich die key-/i-frames für vergleiche zu nutzetn etc.
CameraRick hat geschrieben:Ha, ich hab DNxHR geschrieben aber es war in Wahrheit ein DNxHD. Hab ich Mist gebaut und mich verschaut. Ich habe nun aber auch ein DNxHR HQX (aus AME) im MXF Container gerechnet, das ergibt auch bunte Muster; aber nicht so stückelig, sondern den Streifen wie vorher die anderen.
wenn du das muster in dnxhr mit seiner HD größenbegrenzung testen willst, wäre es vermutlich am besten, wenn dur nur einen 1920x1080 großen ausschnitt des testmusters nutzt, so dass die pixel an der vorgesehenen stelle zu liegen kommen. unter dieser vorgabe wird es dann auch mit allergrößter wahrscheinlichkeit wieder so aussehen, wie in den anderen fällen. so bald man es aber skaliert, ist der ganze zauber weitestgehend zerstört.



CameraRick
Beiträge: 4806

Re: davinci resolve 4:2:2 problem (warnung!)

Beitrag von CameraRick »

mash_gh4 hat geschrieben: wichtig ist aber auch der umstand, dass sie offenbar in den letzten versionen, die sich unter windows nicht mehr auf eine externe quicktime installation stützen, scheinbar nicht zu ffmpeg als ersatz gegriffen haben, sondern entsprechende windows betreibssystem-schnittstellen nutzten.
Zumindest am Mac besteht das Problem auch unter 11.3.1 was ja noch auf der "alten Schiene" fährt, wo sie im Zweifel ja auch nativ auf QT zurück greifen können
mash_gh4 hat geschrieben:hast du ein beispiel, wo das der fall ist?
nach meinem wissensstand hat es bisher noch keine varaiante gegeben, wo ein derartiger unterschied festzustellen ist.
Na, Dein mp4 (was ich im Resolve nicht lesen kann) und die XAVC/AVC Intras, die ich selber gerechnet habe (kannst Du im BMD Forum laden). Da besteht ja eine Diskrepanz?
mash_gh4 hat geschrieben: das könnte u.u. mit den oben beschreibenen umstellungen in 12.5.1 und 12.5.2 zu tun haben. ich hab hier noch immer 12.5 installiert, wo das noch über quicktime läuft, und das file anstandslos akzeptiert wird.

ich kann dir aber gern ein gewöhnlicheres h.264 file generieren, nur ist es halt bei long GOP materal immer ein bisserl problematisch, wirklich die key-/i-frames für vergleiche zu nutzetn etc.
Ach so, also hast Du auch noch QT installiert? Wäre ja spannend zu wissen, ob es da auch statt findet
mash_gh4 hat geschrieben: wenn du das muster in dnxhr mit seiner HD größenbegrenzung testen willst, wäre es vermutlich am besten, wenn dur nur einen 1920x1080 großen ausschnitt des testmusters nutzt, so dass die pixel an der vorgesehenen stelle zu liegen kommen. unter dieser vorgabe wird es dann auch mit allergrößter wahrscheinlichkeit wieder so aussehen, wie in den anderen fällen. so bald man es aber skaliert, ist der ganze zauber weitestgehend zerstört.
Der genaue Zauber ja, aber der generelle aber anscheinend nicht :) wie gesagt habe ich auch ein DNxHR in nativer Auflösung gerechnet, und genau wie im (skalierten) DNxHD treten Farbartefakte auf. Das sagt mir dass selbst wenn man es skaliert das Problem sehen kann, wenn auch leicht anders (aber da bin ich nicht pingelig, problematisch ist problematisch)



mash_gh4
Beiträge: 4716

Re: davinci resolve 4:2:2 problem (warnung!)

Beitrag von mash_gh4 »

CameraRick hat geschrieben:
mash_gh4 hat geschrieben:hast du ein beispiel, wo das der fall ist?
nach meinem wissensstand hat es bisher noch keine varaiante gegeben, wo ein derartiger unterschied festzustellen ist.
Na, Dein mp4 (was ich im Resolve nicht lesen kann) und die XAVC/AVC Intras, die ich selber gerechnet habe (kannst Du im BMD Forum laden). Da besteht ja eine Diskrepanz?
ich seh da keine diskrepanz -- sie zeigen doch in beiden fällen keine farbfehler, so fern man sie überhaupt zu öffnen vermag....

das widerspricht auch deiner these, wonach es etwas mit dem ffmpeg encodieren zu tun haben könnte, weil es sich eben in diesem fall auch bei verwendung von ffmpeg nicht auftritt.



CameraRick
Beiträge: 4806

Re: davinci resolve 4:2:2 problem (warnung!)

Beitrag von CameraRick »

Ha! Da hab ich mich verlesen. Ich hatte angenommen dass es dort passiert! Mea culpa!

Gegen meine These spricht auch, dass es auf OSX in alter wie neuer Resolve-Version zutrifft.

Im Grunde ist es auch egal, was ich für Thesen aufstelle, die Leute bei BMD werden da einen besseren Blick drauf haben und das schnell erkennen.
Immerhin sind des Programmierer einer Hollywood-Software, nicht wahr ;)



CameraRick
Beiträge: 4806

Re: davinci resolve 4:2:2 problem (warnung!)

Beitrag von CameraRick »

mit dem neuen Update kommt es bei mir nicht mehr vor :)



 Aktuelle Beiträge [alle Foren]
 
» Interessante Firmware-Updates für Sony Alpha 1, 7S III und 7 IV
von rush - Fr 7:14
» Uwe Boll: Wie man Filme produziert ohne pleite zu gehen!
von 7River - Fr 7:06
» Nach 7 Jahren mit der OG BMPCC finde ich das Bild noch immer schön.
von Frank Glencairn - Fr 6:22
» >Der LED Licht Thread<
von Frank Glencairn - Fr 5:57
» Was schaust Du gerade?
von Darth Schneider - Fr 5:56
» Venice 2 Bildqualität zum halben Preis? Sony Burano Sensortest
von cantsin - Fr 0:52
» Sondergagen - Wer aufmuckt, wird nicht mehr besetzt
von macaw - Do 23:39
» Nikon stellt NIKKOR Z 28-400mm f/4-8 VR Superzoom-Objektiv vor
von iasi - Do 22:45
» FCPX/Motion, DaVinci/Fusion... Tipps&Tricks
von roki100 - Do 22:27
» Panasonic AG-UX90 Phantomspeisung defekt?
von Fabi283 - Do 22:03
» Mac SSD Speed Messung?
von TomStg - Do 21:43
» Neues SIGMA 50mm F1,2 DG DN | Art Objektiv wiegt 745g
von dienstag_01 - Do 21:21
» Deity Sidius TC Sync Software
von pillepalle - Do 19:58
» Red Komodo 6K + Gimbal, Advanced Ring Grip und viel Zubehör
von Sevenz - Do 19:01
» Camera Update 8.6: Viele neue Funktionen für Blackmagic Kameras
von slashCAM - Do 17:42
» Tieraufnahmen mit dem MKE600 + H1 Essential rauschen
von Swat - Do 16:06
» 4 Gründe hartes Licht zu nutzen
von ruessel - Do 15:45
» [gelöst] 3.5mm Klinkenstecker Überwurfmutter
von Skeptiker - Do 14:42
» Panasonic S5 - Allgemeine Fragen, Tipps und Tricks, Zeig deine Bilder/Videos usw.
von Darth Schneider - Do 13:49
» -SONY FX- Erfahrungsaustausch
von rush - Do 13:40
» AOC bringt 44.5" OLED-Riesenmonitor mit 98.5% DCI-P3
von MK - Do 12:07
» Adobe führt die neue Funktion "Structure Reference" in Firefly ein
von slashCAM - Do 10:54
» Exhuma - die Südkoreaner können erfolgreiche Filme drehen
von -paleface- - Do 8:46
» Was hörst Du gerade?
von roki100 - Do 0:22
» Sony A9 III im Praxistest - ein echter Überraschungscoup auch für Filmer
von Mantas - Mi 23:27
» Video Pro X stürzt beim Multi Cam Schnitt ab
von MisterX - Mi 21:47
» Verschachtelte Timeline im richtigen Seitenformat
von Clemens Schiesko - Mi 18:43
» Untertitel in FCPX bei vorhandener Textdatei?
von R S K - Mi 18:34
» Deckenlicht mobil abschatten
von Frank Glencairn - Mi 17:31
» LUTs für Canon R6 Mark II
von TomStg - Mi 12:24
» RED versucht User nach Übernahme durch Nikon zu beruhigen
von dienstag_01 - Mi 11:52
» Entfesseltes Storytelling mit der Video-KI Sora?
von Frank Glencairn - Mi 5:54
» Slashcam 2001 - Das Internet vergisst nichts!
von macaw - Di 21:37
» Dehancer Pro - Filmsimulation auf höchstem Niveau
von Frank Glencairn - Di 18:54
» Wie Dune Teil 2 entstand - DoP Greig Fraser und Hans Zimmer im Interview
von iasi - Di 13:32