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: 4881

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: 26509

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: 4881

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: 4881

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: 4881

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: 4881

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]
 
» Die beste Hardware für KI-Video - oder was man wirklich (nicht) braucht...
von Totao - Di 13:57
» Vegas Pro 23 ist da - mit Keyframe Editor und mehr GPU-Beschleunigung
von slashCAM - Di 13:14
» Nikon deaktiviert Authenticity Service für Z6 III
von Alex - Di 13:07
» D-Cinelike Material mit Avidemux kürzen in D-Cinelike möglich?
von Videopower - Di 11:24
» Google Pixel 10 Pro (XL) kommt mit Generativer KI direkt in der Kamera
von cantsin - Di 10:11
» Nikon Z5 II mit interner RAW-Aufzeichnung - Debayering, Rolling Shutter und Dynamik
von enii - Di 8:45
» !!BIETE!! GTX 1080 & GTX 970
von klusterdegenerierung - Mo 21:31
» !!BIETE!! 3x Godox SL-60W in Silent Version mit Noctua Lüfter!
von klusterdegenerierung - Mo 21:30
» Camcorder / Kamera für Konzertaufnahmen innen
von Bildlauf - Mo 19:41
» Nikon Z6 III - Sensor-Bildqualität, Rolling Shutter, Dynamik - Günstige Z8 für Filmer?
von roki100 - Mo 19:14
» Blackmagic Design Production Camera 4k in 2025?
von roki100 - Mo 18:58
» Davinci Resolve ipad Musik einfügen
von vaio - Mo 16:47
» Philips Brilliance 27E3U7903: 5K-Monitor mit Thunderbolt 4 und Calman-Ready
von cantsin - Mo 16:01
» SMPTE-2110 für Blackmagic Converter, Audio Monitor, SmartView und Ethernet Switch
von slashCAM - Mo 13:24
» DJI Mini 5 Pro kostet so viel wie Mini 4 Pro
von patfish - Mo 0:46
» AJA IP25-R, UDC-4K und BRIDGE LIVE für Profi-Video-Workflows
von slashCAM - So 9:48
» Nanlux Evoke 600C und Evoke 150C - Vollfarb-LED-Leuchten mit neuer Achtfarben-Technik
von slashCAM - Sa 14:21
» Neue Nanlux Nebula C8 Light Engine - Acht Farben für präzisere Lichtgestaltung
von medienonkel - Sa 14:13
» Dolby Vision 2 - KI-optimiertes Bild, neues Tone-Mapping und Authentic Motion
von radneuerfinder - Sa 10:26
» Sachtler Stativ zu verkaufen
von Arno Muth - Sa 9:59
» Motor Smart: Intelligenter AutoFocus-Motor von PDMovie nutzt LiDAR und KI
von roki100 - Sa 0:30
» Nikon Z6III bekommt u.a. Auto-Capture, USB-Streaming, Vogelmodus
von cantsin - Fr 22:20
» Wie SDI Video in Netzwerk streamen?
von prime - Fr 21:19
» Was hast Du zuletzt gekauft?
von rush - Fr 21:08
» Preview auf objektbasierte Maskentools in der Premiere Pro Beta
von slashCAM - Fr 20:27
» Blackmagic DaVinci Resolve Studio ab sofort auch mit monatlicher Lizenz
von Darth Schneider - Fr 20:04
» Setup and forget Kamera für Livestream
von Darth Schneider - Fr 19:17
» Meike EF-L-Mount drop in filter adapter
von rush - Fr 6:56
» Sony TRV730E | VHS Passthrough?
von Jott - Do 23:23
» Neu und kostenlos - Adobe Premiere für iPhone
von slashCAM - Do 15:03
» Kostenlose IFA-Masterclass - Leo Keller über visuelles Storytelling mit der FX2
von Jominator - Do 13:13
» Sammlerstück möchte den Besitzer wechseln
von Jott - Do 11:14
» DR ipad externe SSD einbinden
von Jott - Do 8:56
» Viltrox bringt neues AF 56mm F1.2 Pro - und tritt L-Mount-Allianz bei
von GaToR-BN - Do 4:43
» Konkurrenz für IMAX - Neues HDR-Premiumkinoformat Vue Epic für Europa
von iasi - Mi 20:41