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

Frage von mash_gh4:


im resolve forum hat ein kollege vor einigen tagen ein ziemlich spannendes problem beschrieben:

https://forum.blackmagicdesign.com/view ... 21&t=52038

es geht dabei um farbartefakte, die ganz offensichtlich nur im resolve zeigen wenn 4:2:2 material importiert wird. offenbar tritt es nicht auf, wenn 4:4:4 oder 4:2:0 footage impportiert wird. die farbaweichungen betreffen zwar wirklich nur ganz kleine details, die einem bei der betrachtung des gesamtbilds kaum auffallen, aber sie werden leider auch in die resulierenden ausgaben vom resolve hineingerendert, was das proroblem doch ziemlich ernst erscheinen lässt. in allen anderen programmen zeigen sich keine vergelichbaren störungen, wenn man die selben files untersucht.

hier ein ganz kleiner (sehr unscharfer) 100x50 pixel aussschnitt, um die art der störung zu illustrieren:

zum Bild


darüber, wo die gründe für dieses verhalten zu suchen sind, rätseln bisher alle betroffen und interessierten. mir ist es jedenfalls bisher nicht gelungen, den betreffenden effekt mit synthetischen testmustern einfach zu reproduzieren, obwohl er sich in den betreffenden beispielen ziemlich einfach aufzeigen lässt und auch nach größere veränderungen am ausgangsmaterial erhalten bleibt. so kann man beispielsweise in den betreffenden ausgangsfiles die farbinformation völlig eliminieren (saturation=0) und trotzdem zeigen sich im resolve diese falschfarben, obwohl das bild ja eigentlich nur mehr grautöne enthält. in jedem anderen programm zeigt sich dann natürlich auch nur mehr ein einzelner kleiner punkt in der mitt des vektorskops, im falle vom resolve allerdings ein strich in der grün-mangenta-achse.

es würde mich mich wirklich freuen, wenn einer von euch bereits eine treffende erklärung für dieses verhalten bei der hand hat. wie gesagt, bisher rätseln noch alle über dieses problem. die meisten gehen allerdings davon aus, dass es sich tatsächlich um einen gravierenden fehler im umgang mit dem farbunterabtastung im resolve handelt, weil es sich eben in praktisch allen anderen programmen nicht in dieser weise zeigt.

leider ist ja BMD im umgang mit bugreports und der entsprechenden korrektur alles andere als vorbildlich. gerade, wenn es keine rückmeldung seitens der verantwortlichen auf entsprechende berichte und hinweise im benutzerforum gibt, kann man fast immer davon ausgehen, dass sie das problem ohnehin selbst reproduzieren können, aber es lieber einfach unter den tisch zu kehren versuchen. das ist leider auch insofern problematisch, weil auf diese weise ganz gravierende mängel (bspw. frame accuracy) oft über jahre hinweg nicht behoben werden. es bleibt einem also benutzerseitig oft nichts anders übrig, als um derartige stolpersteine durch bereichte anderer betroffener zu wissen, um sie weitestgehend zu umschiffen. in dem fall ist das aber gar nicht so einfach, weil es ja vermutlich bei jeder bearbeitung von 4:2:2 material auftreten könnte, und nur sehr schwer früh genug zu erkennen ist.

wie gesagt, vielleicht hat einer von euch mit derartigen schon gekämpft bzw. bessere ratschläge auf lager?



Antwort von sgywalka is back:

Ich habe das schon mal vor kurzem gehabt-und natürlich wollte ich net fragen-weil dann
binich der Watschenbaum.
Ich war mir gar net sicher ob ich da was versemmelt habe und es vermurkst, oder ob ich
da sehe, was ich sehe. Und es ist nur bei einem kurzen Streifen..drum vermute ich....
Wenn ich wieder bei bin, suche ich den verflixten ( böse böse böses 4-2-2-monsda) File.

ich dachte immer ich bin alters-para-noid :)



Antwort von sgywalka is back:

Blöde Nebenfrage!
Auf welchem MOni hast Du / dein Kollege des angegeuckt?
Mir dämmert da was, is es ein I-mac oder Arbeitsmoni--- ungefähr? Grüße..
Messe-hunger



Antwort von mash_gh4:

Auf welchem MOni hast Du / dein Kollege des angegeuckt?
Mir dämmert da was, is es ein I-mac oder Arbeitsmoni--- ungefähr? Grüße.. sorry, das hab ich vergessen zu erwähnen:
wenn man das ganze über eine decklink karte auf einen externen schirm ansieht, was ja in den meisten fällen nur in 4:2:2 erfolgt, sind die artifakte nicht sichtbar, sehr wohl aber in der GUI ansicht. in diesem fall ist also die voransicht über die i/o karten eher irreführend, da ja der fehler in die resultierenden files sehr wohl eingebacken wird, und dort dann auch in jedem programm beim abspielen oder weiterbearbeiten zu sehen ist :(

wäre interessant, wenn du tatsächlich ein weites beispiel anzubieten hättest, das von diesem problem betroffen ist.

ich hab selbst hab auch den eindruck, dass mir derartige störungen schon früher untergekommen sind, aber erst jetzt glaube ich sie langsam ein bisserl klarer zuzuordnen und eindeutig erkennen zu können.



Antwort von Tscheckoff:

@mash_gh4:

Hatte ich auch schon mit 4:2:2 10 Bit DNxHD Material.
Aber in der Ausgabe war es nicht mehr zu sehen.
(Also nur im Rendering innerhalb der GUI.)

LG



Antwort von mash_gh4:

Hatte ich auch schon mit 4:2:2 10 Bit DNxHD Material.
Aber in der Ausgabe war es nicht mehr zu sehen.
(Also nur im Rendering innerhalb der GUI.) in welchen format bzw. welcher unterabtastung hast du rausgerendert?



Antwort von Tscheckoff:

Einmal Cineform YUV 10 Bit (sollte 4:2:2 haben) und das andere mal war es nur H.264 mit höherer Qualität.
(Da ansonsten die Files zu groß geworden wären für nen Kollegen der sie haben wollte ^^.)
In welchem Format gibt denn der Kollege aus?

/Edit:/ Ah. Ok. Hab mir mal den Thread durch gesehen.
Komische Sache ja.

LG



Antwort von Tscheckoff:

Hmm. Eigenartig - Kann es sein, dass das Problem neu ist (seit einem der letzten Updates)?
Habe gerade nochmals rum gespielt - Und er gibt wirklich eigenartige Patterns aus.
(Hab jetzt schon länger nur noch mit dem internen Codec der GH4 gearbeitet und nicht mit den externen DNxHD Files.)

Egal was man raus wirft bzw. sobald man z.B. DNxHD 4:2:2 als Quelle hat.
(Probiert habe ich es gerade mit H.264, DNxHR 444, Cineform und ProRes.)
Vielleicht ein Bug in der neueren DaVinci Version ?!? Habe die 12.5.1.034 drauf.

Möglich, dass es bei mir damals auch nur die normalen Scaling-Moirés waren.
(Die beim Live-Rendering in der GUI ja gern mal auftreten.)

LG



Antwort von mash_gh4:

hab jetzt den nachweise auch noch um einen sythetischen testmuster erweitern können, das aufzeigt, in welchen pixelkombinationen das problem tatsächlich in erscheinung tritt bzw. wie groß der anteil bezogen auf die kombinatorischen möglichkeiten ist.


zum Bild


leider sind die entsprechenden ergebnisse schlimmer ausgefallen als ich es erwartet hätte. :(

man muss sich nämlich vor augen halten, dass dieses problem sich ja leider nicht nur an konturen zeigt, sondern auch überall dort, wo material mit realtiv wenig kompressionsverlusten aufgezeichnet wird, so dass das dithering und rauschen der kameras auch tatsächlich noch im material enthalten ist. ich bin mir mittlerweile ziemlich sicher, dass sehr vieles von dem, was mich an extern aufgezeichnetem GH4 V-log material regelmäßig wieder entsetzt hat, vermutlich diesem problem zuzuschreiben sein dürfte. :(






Antwort von domain:

Bei maximaler Kontrastaufsteilung sieht das dann so aus:


zum Bild

Interessant, dass neben Grün und Magenta auch noch ein Blau- und Gelbanteil sichtbar wird.
Wird bestimmt in kürzester Zeit einen Patch von BMD geben.



Antwort von CameraRick:

Der Beispielclip aus dem BMD-Foren-Thread ist leider offline, hat den noch wer herum liegen?

Oder funktioniert das auch wenn ich mir selber so ein DNxHD aus einer höherwertigen Datei herstelle?



Antwort von Frank Glencairn:

Welche Resizing und Aliasing Einstellungen hast du denn in Resolve?



Antwort von rudi:

Ich könnte mir vorstellen, dass es sich hierbei um eine falsche Platzierung der Sample-Orte bei der YUV-RGB Konversion handelt. (Ich klinge jetzt ja schon fast wie Wowu;)
Drum zur Erklärung einmal der Wikipedia Beitrag zur Farbunterabtastung:

https://de.wikipedia.org/wiki/Farbunterabtastung

Dort sieht man in der Mitte des Artikels schön dargestellt, dass die Abtastpositionen des Choma-Signals je nach Unterabtastung an verschiedenen Orten stattfinden kann. (An oder auch zwischen den Y-Pixeln). Wird beim Decodieren diese Abtastposition falsch zurückgerechnet, kommst es zu Chrominanz-Verschiebungen, wie man sie hier auch sieht.

Mein bescheidender Verdacht: Der neue ProRES Decoder:
Dafür spricht, dass das durchgereichte 4:2:2 ohne RGB-Konvertierung ja sauber ist. Und 4:2:0-MOVs sollen ja auch ohne Chroma-Verschiebungen rauskommen.
Es könnte auch der MOV-Dewrapper beteiligt sein.
Gegenbeweis wäre möglich wenn im Netz auch andere, nicht MOV-Files auftauchen, bin da aber nicht auf dem Laufenden...



Antwort von motiongroup:

Versucht das mal unter OS X zu testen ..



Antwort von dienstag_01:

Dort sieht man in der Mitte des Artikels schön dargestellt, dass die Abtastpositionen des Choma-Signals je nach Unterabtastung an verschiedenen Orten stattfinden kann. (An oder auch zwischen den Y-Pixeln). Ich vermute mal stark, dass du versuchst, reale Positionen aus einer schematischen Darstellung zu interpretieren. Witziger Gedanke ;)



Antwort von CameraRick:

Versucht das mal unter OS X zu testen .. Das würde ich ja, aber brauche dafür Material :(

Hat jemand einen Clip parat, wo es bei ihm auftritt?



Antwort von motiongroup:

Ganz unten von Martin Schitter vermutlich Mash

https://forum.blackmagicdesign.com/view ... 38#p301535



Antwort von rudi:

Dort sieht man in der Mitte des Artikels schön dargestellt, dass die Abtastpositionen des Choma-Signals je nach Unterabtastung an verschiedenen Orten stattfinden kann. (An oder auch zwischen den Y-Pixeln). Ich vermute mal stark, dass du versuchst, reale Positionen aus einer schematischen Darstellung zu interpretieren. Witziger Gedanke ;) Mein Glaube ist unerschütterlich, was schert mich da die Praxis? ;)

Aber im Ernst: Ein weiterer Hinweis, dass es mit Chroma-Samplingorten zu tun haben könnte: Nehmt mal das Prores-File von mash (http://users.mur.at/ms/attachments/combinatoric.mov)
und legt es in eine Resolve Timeline (Achtung, Projektbreite muss 2048 sein, weil das File auch 2048 hat).

Ihr seht die Problemfarben anschließend in jeder Skalierung außer bei 50 Prozent Skalierung. Denn nur bei 50 Prozent sind die Sample Orte für Y und UV immer korrekt, egal welche Positionen man fürs Chroma-Upsampling annimmt. Einfacher gesagt: Nur bei 50 Prozent findet kein Chroma-Resampling statt, sondern nur ein Luma-Downsampling. Es ist der einzige mathematische Fall, in dem es nicht zu einem Chroma-Resampling kommt. Das könnte schon ein wichtiger Hinweis sein, dass der Hund beim Chroma-Resampling begraben ist.






Antwort von CameraRick:

Dass da so Streifen im Bild sind ist schon recht? In den Beispiel-JPEGs hier im Thread sieht man die nicht daher frage ich.

Schon lustig, das passiert bei mir auch; Resolve Studio, 12.5.1 auf OSX 10.10
Er erkennt die Datei im Resolve auch als Prores 422 HQ, Quicktime beschreibt den Codec nun aber sehr komisch.
Ich habs auch fix an einem iMac mit 11.3.1 Lite getestet (irgendein El Capitan), selbes Verhalten.
Sobald ich die Datei via Quicktime als Prores 4444 abspeichere, sieht es normal (also nicht bunt) aus.
Ich habe mal so alle Settings bzgl Scaling im DaVinci ausprobiert, es auf ACES gestellt und was nicht alles, und es passiert jedes mal. Ich habe keine I/O Karte an dieser Workstation, daher kann ich da nichts schauen.
Im Nuke und AE klappt es auch ohne Probleme.

Wenn ich meine gewandelte Datei wieder als 422 HQ im Quicktime umwandle, passiert es auch direkt wieder. Egal ob ich die Filrerung für 444 Quellen einschalte oder nicht.


Daraus schließe ich

- es ist kein Windows Problem
- es bestand schon vor v12
- fuck, das ist mega gefährlich



Antwort von motiongroup:

Conclusio... Schrott



Antwort von mash_gh4:

Bei maximaler Kontrastaufsteilung sieht das dann so aus:

zum Bild

ich würde es eher mit einer sehr hohen anhebung der farbsättigung herausheben:

zum Bild

Interessant, dass neben Grün und Magenta auch noch ein Blau- und Gelbanteil sichtbar wird. ich glaube, das zeigt sich nur in dem dürftigen 8bit png screenshot, den ich hier zu illustrationszwecken benutzt habe. in wahheit liegen die störungen all in der grün-mangenta achse.

nur nocheinmal als versuch einer klarstellung, was dieses bild eigentlich aussagt:

es ist einfacher grauverlauf, sondern ein geflecht von linien die jeweils in horizonaler und vertikaler richtung ihre helligkeit von 0 bis 1023 ändern -- hier ein auschnitt:

zum Bild

auf diese weise kann man über die platzierung der entsprechenden verfärbungen ganz genau sagen, bei welchen benachbarten grauwert-kombinationen sich der fehler zeigt.

es ist eine störung die über die ganze diagonale läuft -- d.h. man findet sie über den ganze helligkeitsbereich.

der fehler zeigt sich nur, wenn beide pixel relativ ähnliche werte aufweisen. wobei allerdings ein erstaunlich großer bereich betroffen ist.
Wird bestimmt in kürzester Zeit einen Patch von BMD geben. das wäre natürlich zu wünschen. wirklich sicher wäre ich mir allerdings nicht. mir sind mind. 3 ähnlich gravierende probleme (betreffend bspw. die framegenaue verarbeitung) bekannt, die von benutzern seit jahren bemängelt und in ihren auswirkungen immer wieder klar beschrieben wurden, aber trotzdem bisher nie gefixt wurden.

die tatsache, dass BMD auf solche hinweise gar nicht eingeht, sondern wir uns vielmehr schon daran geöhnt haben, dass es gewissermaßen als bestätigung für einen reproduzierbaren bug aufzufassen ist, wenn keine antwort, die sofort mit einem benutzerseitigen fehler kontert, zu vernehmen ist.

wenn man einmal erlebt hat, wie das in anderen projekten gehandhabt wird -- ich denke da beispiel an natron, wo gravierende bugs oft in stunden, spätestens aber innerhalb von ein paar tagen gefixt werden, oder aber auch an "nuke", wo zumindest wirklich gut nachvollziehbare fehlertickets existieren und bei jeder neuen release ganz genau aufgelistet wird, welche probleme behoben wurden, aber auch, welche mängel noch offen sind -- wirkt es ziemlich enttäuschend, wie das von BMD gehandhabt wird.

prinzipiell würde ich behaupten, das jede software fehler und verbesserungspotential enthält. das ist nicht wirklich das problem. entscheident ist die art und weise, wie man diesem problem konstruktiv begegnet!



Antwort von CameraRick:

Weiß nicht ob ich Open Source Projekte so sehr da mit rein nehmen würde, das sind ja ganz andere Strukturen. Bei BMD wird nach Feierabend niemand mehr daheim sitzen und was am Code ändern können.
The Foundry läuft auch immer ein wenig als Negativbeispiel, habe erst vor kurzem einen Script-Breaking Bug reported, da hat man mich direkt angeschrieben dass es ein Known Bug ist, und mir den Link geschickt. Der wurde 2010 gemeldet...

Wie dem auch sei, das ist ganz schön krass.
Ich will mal versuchen wie das mit verschiedenen Codecs usw aussieht, mit einer einheitlichen RAW Quelle die ich auch posten kann. Mal schauen wie sich das alles so verhält.



Antwort von mash_gh4:

Weiß nicht ob ich Open Source Projekte so sehr da mit rein nehmen würde, das sind ja ganz andere Strukturen. Bei BMD wird nach Feierabend niemand mehr daheim sitzen und was am Code ändern können. da hast schon recht! ich will es auch nicht überstrapazieren -- wobei ich schon glaube, dass auch kommerzielle unternehmen sich manches von den gepflogheiten in der freien welt abschauen könnten, damit die qualität jener porodukte, auf die wir in unserer täglichen arbeit angewiesen sind, besser wird.

im falle von BMD sehe ich persönlich das so, dass es zwar natürlich der "firmenideologie" zuzuschreiben ist, wenn man sich in solchen dingen derart zugeknöpft und paternalistisch gibt -- ich würde also keinem einzelnen entwickler od. produktmanager einen persönlichen vorwurf daraus machen --, aber in summe nimmt man es doch in etwa so wahr, wie man einem normalen ungezwungenem gegenüber begegnet. dort würde man vermutlich auch von "arroganz" od.ä. sprechen, wenn mit einem in derart asymmetrischer weise umgesprungen wird...

trotzdem: das erwähne ich nur, weil ich mich ja öfter darüber ärgern muss.
im konkreten fall ist es aber natürlich wichtiger, dass einfach nur eine lösung gefunden wird, diesen mangel aus der welt zu schaffen...
The Foundry läuft auch immer ein wenig als Negativbeispiel, habe erst vor kurzem einen Script-Breaking Bug reported, da hat man mich direkt angeschrieben dass es ein Known Bug ist, und mir den Link geschickt. Der wurde 2010 gemeldet... ja -- wirklich schnell und zielgerichtet entwickeln sie leider offenbar gegenwärtig nicht, trotzdem ist ein tolles programm, auf das man sich in den meisten fällen wirklich verlassen kann. mir erscheint es deutlich transparenter und sauberer konzipiert als resolve oder fusion.
Ich will mal versuchen wie das mit verschiedenen Codecs usw aussieht, mit einer einheitlichen RAW Quelle die ich auch posten kann. Mal schauen wie sich das alles so verhält. wie gesagt, ich galube, dass es ganz unabhängig vom verwendeten codec in allen fällen, wo 4:2:2 subsampling genutz wird, aufzutreten scheint...

vermutlich braucht man wirklich nur die eine zeile im code, wo sich die entsprechende umrechnungsformel findet bzw. die verwendeten datentypen klarerer ersichtlich sind, ansehen, und man kann das verhalten augenblicklich rational erklären. ;)



Antwort von Frank Glencairn:

Conclusio... Schrott Klar, der "Schrott" ist gut genug, für einen guten Teil aller Hollywood Blockbuster, aber wir hier haben natürlich viel höhere Ansprüche.

Hab mal das Testfile von Mash in Resolve geworfen. Egal mit welchen Einstellungen, nirgendwo tritt dieser Effekt auf. Weder im Vorschau Fenster, noch auf einem der 2 Video Monitore.



Antwort von motiongroup:

Missinterpretation.. nicht Resolve ist Schrott sondern das Ergebnis;)



Antwort von CameraRick:

Hi mash,

ich wollte BMD nicht verteidigen, finde viele der Probleme die Resolve und Fusion haben unter aller Sau; gerade weil es so viele (IMHO) unnötige neue Features gibt, aber viele Bugs einfach liegen bleiben.

Fusion sehe ich in vielen Belangen hinterm Nuke, nicht nur in der Kommunikation nach außen. Und eine beinahe ganze Branche sieht das wohl auch so :)
Auch wenn ich hin und wieder sauer auf den The Foundry Support bin, ich kenne auch den von BMD, und solang es nicht um Kameras geht ist der ziemliche Grütze.


Vielleicht können wir das Problem auf irgendwas eingrenzen. Bei Frank tritt es nicht auf.
Vielleicht wenn man OS, GPU, Treiber Version etc sammelt? Ob QT noch installiert ist, oder nicht?
Ich hab getestet auf

Mac Pro OSX 10.10.5, Resolve Studio 12.5.1, Dual FirePro D700 (UI GPU nicht für Rendering genutzt)
iMac OSX 10.11.5, Resolve Lite 11.3.1, GTX 680MX

Daheim kann ich noch meinen PC+Laptop durch checken.
Klar, der "Schrott" ist gut genug, für einen guten Teil aller Hollywood Blockbuster, aber wir hier haben natürlich viel höhere Ansprüche. Auch wenn eine Software für High End benutzt und gemocht wird, darf man sich wohl pikieren wenn sie offensichtlich nicht ordnungsgemäß funktioniert :)



Antwort von Frank Glencairn:

Resolve Studio 12.5.2, Win 7, GTX 980, Decklink 4k Extreme, Quicktime installiert






Antwort von mash_gh4:

Vielleicht können wir das Problem auf irgendwas eingrenzen. Bei Frank tritt es nicht auf. ich fürchte, dass er das tiff file und nicht den 4:2:2-clip verwendet hat.
bisher haben sich noch bei allen kollegen, die es mit material von entsprechender farunterabtastung versucht haben, ähnliche artifakte gezeigt -- wenigstens in GUI und renderresultaten.
Klar, der "Schrott" ist gut genug, für einen guten Teil aller Hollywood Blockbuster, aber wir hier haben natürlich viel höhere Ansprüche. Auch wenn eine Software für High End benutzt und gemocht wird, darf man sich wohl pikieren wenn sie offensichtlich nicht ordnungsgemäß funktioniert :) genau diese hollywood phrasen, kann ich wirklich nimmer hören! :(

ich versteh gut, warum leute auch dort mit verhältnismäßig einfacher und gebräuchlicher software, aber einem handwerklichen geschick, das die meisten von uns nicht mitbringen dürften, wirklich großartiges leisten. und resolve hat ja auch definitiv stärken, wo es um die gestalterischen relevanten hilfsmittel und schwerpunktsetzungen geht, nur in vielen technischen details und in seiner ausgesprochen verlogenen vermarktungspolitik ist es in meinen augen leider wirklich eine mittlere katastrophe!



Antwort von Frank Glencairn:

Okay hab jetzt den clip probiert und seh es jetzt auch.

Ist womöglich ein QT Problem.

Hab das Tiff mal testhalber exportiert.

AVI > unkomprimiert > 4:2:2 > alles gut
QT > unkomprimiert > 4:2:2 > Bunte Muster



Antwort von mash_gh4:

Okay hab jetzt den clip probiert und seh es jetzt auch. "prima!" ist wohl in dem fall als antwort nicht wirklich angebracht. ;)
Ist womöglich ein QT Problem. das ist nicht völlig auszuschließen...
das DNxHD file, mit dem die ganze geschichte begonnen hat, war auch in einem quicktime container. in dem fall müsste sich das problem aber auch in einigen anderen programmen zeigen, die sich auf quicktime stützen...

so viele möglichkeiten bzw. container- und fileformate mit farbsubsamplingunterstützung gibt es ja leider nicht, die resolve import- und exportseitig unterstützen würde.
AVI > unkomprimiert > 4:2:2 > alles gut kannst mir zufälligerweise sagen, welche avi 'uncompressed' 4:2:2 variante resolve unterstützt, damit ich das ohne langes suchen durchprobieren kann?



Antwort von Frank Glencairn:

Variante?

Ich wähl halt AVI, und dann "uncompressed 4:2:2" im Delivery an



Antwort von CameraRick:

Ich habe mal einen Demo-RAW-Clip versucht, leider taucht es da einfach nicht auf. Vermutlich sind die Frequenzen einfach nicht drin.

Ein anderer Testclip den ich hier gefunden hab liegt mir in PR422HQ vor, eine BMPCC war das glaub ich (war bei irgendwas von FXPHD dabei, keine Ahnung). Umgewandelt in 444 ist alles cool.

Ich bin mal Franks Beispiel gefolgt, und habe das File in AVC-Intra Class100 und XAVC Class200 gewandelt. Presets aus dem AME.
Die haben, MediaInfo nach, beide 10bit 422. Aber keine bunten Streifen!

Ergo scheint es wirklich ein QT Problem zu sein. Lustig ist, dass es in keiner anderen Anwendung, QT inklusive, auftritt. Demnach glaube ich nicht dass es ein generelles QT Problem ist, sondern ein Problem vom QT Decoder von Resolve.

//edit
Ich habe derzeit daheim ein kleines Projekt laufen, da arbeite ich mitunter mit DNxHR im MXF Container, damit ich in den Nuke kann. Werde da auch mal schauen wie sich das Testfile in der Umgebung verhält.



Antwort von motiongroup:

Wichtig ist das ihr schon einen Workaround gefunden habt und BM wird dem sicher auf den Grund gehen und den Fehler beheben..
leider ist ja BMD im umgang mit bugreports und der entsprechenden korrektur alles andere als vorbildlich. gerade, wenn es keine rückmeldung seitens der verantwortlichen auf entsprechende berichte und hinweise im benutzerforum gibt, kann man fast immer davon ausgehen, dass sie das problem ohnehin selbst reproduzieren können, aber es lieber einfach unter den tisch zu kehren versuchen. das ist leider auch insofern problematisch, weil auf diese weise ganz gravierende mängel (bspw. frame accuracy) oft über jahre hinweg nicht behoben werden. Ist das bei den anderen Herstellern besser? Ich fand gerade das bei BM die Entwickler relativ gesehen zu den anderen Herstellern sehr präsent sind im eigenen Forum..

Apple nada
Magix nada
Adobe nada
Avid keine Ahnung
Autodesk lowend nada highend absolut..

Im Regelfall meldest einen Fehler ein der bewertet wird und bekommt maximal ne Nachricht über die zu Kenntnisnahme.. und freu dich wenns beim nächsten Patch gefixt ist...wenn überhaupt..



Antwort von mash_gh4:

Ist womöglich ein QT Problem.
...
AVI > unkomprimiert > 4:2:2 > alles gut
QT > unkomprimiert > 4:2:2 > Bunte Muster 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. :(
Ich bin mal Franks Beispiel gefolgt, und habe das File in AVC-Intra Class100 und XAVC Class200 gewandelt. Presets aus dem AME.
Die haben, MediaInfo nach, beide 10bit 422. Aber keine bunten Streifen! 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.
Wichtig ist das ihr schon einen Workaround gefunden habt und BM wird dem sicher auf den Grund gehen und den Fehler beheben.. ob und in welcher weise BMD reagieren wird, erwarten wir natürlich alle sehr gespannt...

wirklich befriedigenden wirken mir die bisherigen workarounds nicht -- dafür ist 10bit 4:2:2 ausgangsmaterial in der wirklichkeit draußen viel zu weit vorbreitet, als dass man es einfach ignorieren könnte...

Ist das bei den anderen Herstellern besser? wie oben schon erklärt, gibt es definitiv beispiele, wo das unvergleichlich besser funktioniert...



Antwort von sgywalka is back:

Wir sind para ( no ) rmal)id!

Ich habe den besagten File gefunden ( is nur ein Fitzelchen von Zitrone mit Schale, also keine 3 sec)

- den originalen
-der " womöglich" fehlerhafte

Der Originale hat es NICHT
Der Fehlerhafte hat es auf einem Computer und auf einem baugleichen ( kann sein das der
ein Uptatde vor/dahinter ist) NICHT.

Ich gehe von irgend einem Handgriff aus, den ich ( oder der scheiss Rechner) gemacht habe, fragt sich nur warum?

Bei weiterem Sichten von Material finde ich nix.Meine Vermutung is ( es war eine normale
BMC 4k Bauern-4k-kamera-für-arme-Filmer) und nach dem Start der Aufnahme, da nach 2,3sec.. das die SSD da oder beim Kopieren ( was auch ein Schwachsin is)

Es ist Freitag = ALKOHOL ( warum 56,45633 % der Kameraleute mit dem Saufen anfangen)...:)



Antwort von sgywalka is back:

12tes IASI_GEBOT: DU SOLLST DIE 5k-RED nehmen! aaaaaaamne :)






Antwort von CameraRick:

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...



Antwort von mash_gh4:

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.
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.
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.
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.



Antwort 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.



Antwort 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 :)



Antwort von mash_gh4:

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.



Antwort von mash_gh4:

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.
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.
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.
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.



Antwort von CameraRick:

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
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?
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
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)



Antwort von mash_gh4:

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.



Antwort 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 ;)






Antwort von CameraRick:

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