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. :(
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.
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.
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 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 :)
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.
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.
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 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.
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 ;)
Rechtliche Notiz: Wir übernehmen keine Verantwortung für den Inhalt der Beiträge
und behalten uns das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
