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.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
ja. damit kann ich am einfachsten das pixelformat und die etwas ungewöhnliche bild-/videogröße sicherstellen.CameraRick hat geschrieben:Ich darf annehmen, dass Du Deine Files mit FFMPEG erstellst?
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.CameraRick hat geschrieben:Ich kann das verlinkte h264 im DaVInci nicht öffnen, das schmeckt ihm nicht.
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.CameraRick hat geschrieben:DNxHR HQX im MXF Contrainer dagegen zeigt andere, spannende Buntmuster
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.CameraRick hat geschrieben:Sollen wir die Unterhaltung eigentlich komplett ins BMD Forum verlagern? Sind ja sonst schon alle da...
Theorie: Resolve nutzt FFMPEG, oder "Teile" davon, zum Dekodieren. Schlecht implementiert, versteht sich.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.
Resolve bleibt beim roten Ausrufezeichen, Fusion weigert sich auch. Adobe liest es ohne Probleme.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. ;)
[...]
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.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.
[...]
ich werde das nachzuvollziehen versuchen.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.
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.CameraRick hat geschrieben: Theorie: Resolve nutzt FFMPEG, oder "Teile" davon, zum Dekodieren. Schlecht implementiert, versteht sich.
hast du ein beispiel, wo das der fall ist?CameraRick hat geschrieben:Daher treten die Artefakte mitunter bei FFMPEG Quellen auf, bei AME aber nicht.
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.CameraRick hat geschrieben:Resolve bleibt beim roten Ausrufezeichen, Fusion weigert sich auch. Adobe liest es ohne Probleme.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. ;)
[...]
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 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.
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önnenmash_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.
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: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.
Ach so, also hast Du auch noch QT installiert? Wäre ja spannend zu wissen, ob es da auch statt findetmash_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.
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 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.
ich seh da keine diskrepanz -- sie zeigen doch in beiden fällen keine farbfehler, so fern man sie überhaupt zu öffnen vermag....CameraRick hat geschrieben: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: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.