Blackmagic DaVinci Resolve 21.0.4 mit X-OCN Unterstützung für Sony FX5 und mehr

[slashCAM]

Blackmagic Design hat ein neues Update für DaVinci Resolve mit wichtigen Neuerungen zum Download freigegeben. Die spannendste neue Funktion für Sony User dürfte die Unter...

Hier geht es zur Newsmeldung auf den slashCAM Magazin-Seiten:
Blackmagic DaVinci Resolve 21.0.4 mit X-OCN Unterstützung für Sony FX5 und mehr

[CameraRick]

API calls für Handles ist auf jeden Fall richtig cool, genau so wie die Selection from Timeline. Find ich toll, dass da endlich wieder richtig nützliche Neuerungen frei geschaltet werden :)

[freezer]

API calls für Handles ist auf jeden Fall richtig cool, genau so wie die Selection from Timeline. Find ich toll, dass da endlich wieder richtig nützliche Neuerungen frei geschaltet werden :)

Ja, meine Scripting API Wishlist im BMD Forum dürfte da ein bisschen geholfen haben den Fokus auf die wichtigen API Erweiterungen zu lenken:
https://forum.blackmagicdesign.com/view ... 2&t=235665

Falls Du weitere Ideen hast, bitte gerne hier (und ich trage das dort nach) oder im BMD Forum im Thread äußern. Ziel ist es, BMD in die richtige Richtung zu schubsen damit wir das in der API bekommen, was wir für das Scripting am dringendsten benötigen.

Je mehr Stimmen, desto besser.

[CameraRick]

Falls Du weitere Ideen hast, bitte gerne hier (und ich trage das dort nach) oder im BMD Forum im Thread äußern. Ziel ist es, BMD in die richtige Richtung zu schubsen damit wir das in der API bekommen, was wir für das Scripting am dringendsten benötigen.

Das ist ziemlich cool, Danke Dir für die Mühe und das Organisieren!

So aus dem Kopf (ich denke mir einfach nur dumme Namen aus, haha):

GetSourceTimeAtTimelineTime() - wir haben GetSourceStartTime und GetSourceEndTime, die geben aber nicht mal den Zeitpunkt bei den Schnittmarken an, sondern die maximal bzw minimal genutzten Zeitpunkte (wenn ein Clip Rückwärts abspielt sind sie verdreht, bei Bounces können die Punkte komplett woanders sein). Das ist zwar cool um eine Best Length zu ermitteln, aber ich würde gerne auslesen können: "welche Framenummer/TC hat Clip 4 bei Rec TC 00:01:03:22" (bei linearen Clips ohne Retimes geht es schon gut, bei linearen Retimes wirds schon ätzender wegen Rundungen, und bei non-linearen Retimes musst Schnittlisten parsen)

SetTimelineResolution() und SetTimelineFPS() - neue Timelines haben immer die Specs der Project Settings. Man kann das hacken, indem man per API die Project Settings ändert, erstellt, und wieder zurück setzt - das ist aber fehleranfällig und unnötig lästig

CopyTimelineItem() - aktuell ist es nicht möglich Clips zu kopieren. Man kann zwar zB eine neue Timeline erstellen und das Media Pool Item mit den gleichen In/Out Punkten platzieren, aber die Crux ist ja im Vorschlag oben absehbar: echte In/Outs habe ich gar nicht, und Retimes kann ich auch nicht 1:1 wieder herstellen. Falls nötig kann ich auch gern ausführen, wozu ich das "brauche" (wie den nächsten Eintrag, könnte man es auch via Python hacken)

PlaceCutAt() (zB atTimelineTime) - man kann keinen Schnitt setzen, via API. Wir haben das richtig dirty gelöst, indem Python den Shortcut für einen Cut an Playhead Position durchführt. Aber dafür müssen auch alle nicht gewünschten Timelines abgesperrt werden, dazu es ist auch sau langsam und blockiert den Computer, weil ich nichts anderes machen kann (weg-tabben löst dann den Shortcut in Firefox aus, haha)


FIXES hätte ich gern für GetSourceStartFrame() und GetSourceEndFrame(); Dir ist sicher aufgefallen, dass ich oben GetSource%Time erwähnt habe, obwohl ich von Frames spreche. Denn GetSource%Frame liefert gern mal Kokolores, wie uns aufgefallen ist, und liegt dann idR +1 Frame daneben. Meine Theorie: GetSource%Frame entspricht GetSource%Time mit "falscher" Rundung, wenn ich mich recht entsinne mit einem math.round(time) / FPS. Resolve scheint aber intern mit einem wilden math.floor(time + 0.00099 ) / FPS zu arbeiten; zumindest konnten wir das Reverse-Engineering so für uns feststellen.
So oder so: GetSource%Frame gibt andere Frames aus, als der Resolve Viewer anzeigt, und das sollte nicht passieren.

Beste Grüße

//edit
Fast vergessen!

Read- und Set{everyItemIn "Retime and Scaling"}() - ich hasse es sehr, dass man nicht alle Settings, die im Inspector in "Retime and Scaling" geführt werden setzen kann. Das nervt auch beim Shortcut Alt+V, dass ich zB "Scaling" nicht einfügen kann. Wenn ich es für einen Clip ändere, und Settings kopieren/einfügen will, sind RePos wertlos wenn das Scaling nicht übernommen wird.

[freezer]

Danke Rick, tolle Vorschläge und Anregungen! Ich habe diese nun ausformuliert und im BMD Thread ergänzt. Schau mal drüber ob ich eh nix vermurkst habe.

Irgendwann werde ich wohl die Hauptliste selbst updaten müssen.

[CameraRick]

Wunder schönen guten Abend wünsche ich! Verzeih die späte Antwort, bewegte Arbeitswoche, hab das Wochenende hauptsächlich gelegen :o)

Ich habe diese nun ausformuliert und im BMD Thread ergänzt. Schau mal drüber ob ich eh nix vermurkst habe.

Erstmal Danke für die Mühe. Das liest sich alles super, und schön zu sehen, dass Du auch schon mal einen PlaceCut gebraucht hättest, haha :)
Einzige Kleinigkeit: beim Bug und dem ersten wird GetSource%Time() nicht weiter erwähnt, da das heute schon ein extrem robustes Workaround ist (gerade beim Bug auch nicht unwichtig, falls da Leute mitlesen, die die Info nicht haben). Es ist mehr lästig, dass GetSource%Frame() nicht sauber funktioniert, zumindest wenn man es nicht weiß. Dann sieht man die Fehler erst spät, oder gar nicht.
War mir noch eingefallen: GetSource%Frame() gibt meistens korrekte Ergebnisse, Retimes sind eben tückisch (auch lineare, nicht nur Bounces), aber bei mixed-FPS tritt es auch auf.
___________________

Wo wir gerade (mal wieder, haha) über die API plaudern, und wir es ja auch mal von Schnittlisten hatte, frag mal ganz naiv gerade raus: hast Du Dich schon mal mehr mit dem Parsen von Schnittlisten beschäftigt, was die "Frame at Timeline Time" Geschichte betrifft? Für unsere Systeme wäre das vollendet-veredelte Schnittlisten-Parsing, auch außerhalb von Resolve, eine immense Arbeitserleichterung.

Bisher haben wir hauptsächlich OTIOs, DRTs, und (FCP7) XMLs untersucht. Letztere speichert In/Out und Timing-Keyframes sehr gut, aber zB keine Tangenten für non-lineare Retimes. OTIOs sind unsagbar spannend, da die ziemlich detaillierte Keyframe-Tabellen mit Tangentenbeschreibung anlegen; aber den internen Offset speichert Resolve dort Im <DynamicZoom> Key, was etwas absurd ist, aber zuverlässig. Das Problem dabei ist, dass dieser Offset integer ist, und ein Retime ist eben nicht immer integer, und dadurch entstehen Offsets (im Grunde das Problem GetSource%Time() vs GetSource%Frame(); für die Berechnung braucht man einfach den Source Float wert, gerundet wird erst am Ende).
Wenn man eine DRT umbenennt, entpackt, und sich dann die dort internen XMLs anschaut, darf man erstmal vieles decoden; danach stellt man aber fest, dass die viel mehr speichert (auch Auflösung usw, was super praktisch sein kann). Jedenfalls haben wir dann heraus gefunden, dass dieser Offset (den die OTIO in DynamicZoom speichert), dort 1. float ist und 2. auch mit <in> viel sinnvoller benannt ist. Dann fällt auf: die Keyframetabelle in der DRT ist 1:1 identisch mit der OTIO. Unsere Theorie: DRT kamen in 17 dazu, OTIO in 18.5; da OTIO einfach nicht komplett "durch definiert" sind (und vermutlich auch nicht werden, Du hast mich ja schon mal drauf aufmerksam gemacht, dass das eher brach liegt), hat BMD vermutlich einfach seine DRT Beschreibungen quasi 1:1.5 in der OTIO zum Einsatz gebracht. Da das Entpacken/Decoden der DRT mehr Processing kostet (wenn auch nicht viel, aber spürbar), nutze ich selber gerade einen Mix aus API Calls (für GetSource%Time() für Min/Max Werte) und die Keyframes+Tangenten aus der OTIO (ist auch weniger fehleranfällig, und beim Debuggen zumindest ohne weiteres lesbar).

Wir wollen eigentlich gern alles auch extern parsen, für die Pipeline. Ich komme mit dem erwähnten Workaround ganz gut klar; ich arbeite gerade an einer Workflow-Integration, um mehrspurige Burn-Ins zu realisieren. Dafür brauchts halt zuverlässige "Frame at Timeline Time" Daten, sonst kann man sich das schenken. Solang Retime-Kurven keine Tangenten haben, ist meine Methode auch in allen Tests 100% spot-on. Sobald Tangenten ins Spiel kommen, habe ich hin und wieder Abweichungen von 1 Frame in Kurven, möglicherweise Rundungsfehler (das gilt für die freien Tangenten in 21, die nur-waagerechten Tangenten aus 20, die nun auch als Option wieder kommen sollen(?) haben wir zwar in Grundzügen verstanden, aber keine brauchbare Mathematik für die Berechnung finden können; ich habe aber auch generell eine Meinung zu diesen Tangenten, haha). Da das alles reverse-engineered ist, kann natürlich auch einfach ein Detail für die Berechnung fehlen.
Die Integration will ich, wenn sie mal fertig ist (aktuell arbeite ich mehr oder weniger am Polishing, ich brauchte etwas Abstand vom Parsing, haha), dann auch FOSS zur Verfügung stellen (ein paar andere Tools, wo das praktisch für wäre, können wir wegen Interna blabla leider nicht zur Verfügung stellen; zugegeben sind die aber auch sehr speziell auf unsere Pipeline-Software zugeschnitten)

Jetzt hab ich hier sehr viel gesabbelt. Die Frage war ja: hast Du damit schon Erfahrung sammeln können? Vielleicht haben wir was übersehen, oder Du hast eine bessere Idee? Ich hab zB noch keinen längeren Blick in FCPXMLs geworfen, und auch nicht in AAFs die ja auch erst irgendwie "geknackt" werden müssten. Falls Du was hast, aber hier nicht teilen kannst/magst, können wir uns auch gern anders vernetzen. Bin selbstredend auch bereit, Infos zu "tauschen" :o)

___________________

Und weil ich noch nicht genug gesabbelt habe, eine kleine Anekdote zum Place-Cut-Call:
Wir nutzen das, um Schnitte von einer Spur auf eine andere zu übertragen (zB um Referenzen Anhand des Conforms zu zerschneiden); spart genug Zeit (und nerven) dass es sich lohnt. Wo es sich richtig gelohnt hat: als ich mit dem Parsen von Retime-Tangenten anfing, brauchte ich zum Prüfen die Frame/TC-Info von jedem Frame im Video. Das abzuschreiben dauert hundert Jahre. Dann dachte ich: zerhacken und mit GetSource%Time() die Info abgreifen, und per Spur in eine CSV schmeißen. Aber das Zerhacken dauert auch ewig, und weil die Testdaten groß sind, hängt es manchmal und dann überspringt man was usw usf, und hat es dann nicht korrekt. Also habe ich mir eine Spur mit Einzelframes vorbereitet (einfach ein Solid für 10f zerhackt, Copy+Paste, wieder Copy+Paste, usw, bis die Timeline voll ist), und dann das Schnitt-Übertragungstool genutzt um alles zu zerhacken. Die Timelines waren nie besonders lang, paar Minuten, aber alter Verwalter hat das ewig und drei Tage gedauert. Und beim ersten Mal hatte ich dann selber erfahren+gelernt, dass man nicht raus tabben kann, haha

Beste Grüße

[freezer]

Ich habe die Analyse und das Reverse Engineering vorerst auf Eis gelegt, der Aufwand beim Entwickeln von Testprojekten, das Testen und Probieren wurde einfach zu zeitaufwändig für meinen Usecase. Zumal da nun ein paar kommerzielle Anbieter am Markt aufgetaucht sind.

FCP XML habe ich mir vollständig dokumentiert aus den offiziellen Unterlagen von Apple.
Meine Idee war, FCP XML und OTIO als Validator für das Reverse Engineering von PPROJ und DRT zu nutzen.

Ich habe als weiteren Validator noch den Timeline Index als CSV exportiert.

Das größte Problem mit der DRT sind die ganzen BLOBS, die man alles erst mühselig dekodieren und dokumentieren muss. Ich habe damit begonnen - aber wie gesagt, das liegt auf Eis.

AAF ist da nochmal ein ganz anderer Brocken, hab da keine ordentliche Dokumentation gefunden - ich vermute man muss das bei Avid lizenzieren um Zugriff auf die API zu bekommen.

[CameraRick]

Heh, verstehe ich absolut. Ich hab zwar auch schon ein paar private Abende damit verbracht, aber es mir abgewöhnt, und jetzt nur noch im Büro "nebenbei", wenn es die Zeit erlaubt, geht dann immer nur träge.

Die exportierte CSV (mit allen Per-Frame-Werten) hatte ich dann immer durch ein Testscript laufen lassen, was die OTIO und Mock-Daten aus Resolve mit dem aktuellen Parser checkt; das war schon brauchbar, weil man innerhalb von Sekunden sehr viele Verifizierungen durchführen und dann tweaken kann. Aber das Vorbereiten der Timelines, CSV usw braucht auch immer gut Zeit. In einer Timeline, die nur um Tangenten ging, habe ich auch die gottlosesten Retime-Kurven meiner Karriere gebaut. So welche, die man seinen schlimmsten Feinden nicht zum Conformen geben würde.

Das Decoding der DRT hatten wir jetzt schon ganz gut am Start, aber wie gesagt: wir sind immer recht gezielt auf die eine Sache, die wir gerade brauchen, unterwegs (wobei ich es mir nicht hab nehmen lassen, das als Text-kodierte Thumbnail auch zu PNG zu exportieren, haha). Ich hab es dann nicht weiter verfolgt weil kein Mehrwert, mein Kollege hatte es etwas mehr ausgereizt aber da ist die Datei so weit umgeschrieben worden dass es viel Leistung fraß. Er hat jetzt angefangen, eine XML-OTIO-Kombi zu fahren: XMLs fehlen die Tangenteninformationen bei Retimes, aber der Rest ist wohl stabil (aber gibt Startframes anscheinend auch nur integer an, ich bin da noch skeptisch). Man kann also daraus recht flott parsen, und bei non-linearen Retimes mit dem Keyframe-Array bzw der Tabelle kurz abgleichen+auffüllen. Dazu hat er ein neues Tool gebaut, wo Du XML+OTIO reinlädst, und in Resolve durch die Timeline scrollst; das Tool bleibt Sync und zeigt in Echtzeit den Frame an, den es parsen würde, und man gleich es dann (manuell) mit der Ansicht im Resolve ab. Falls es abweicht, trägt man das für die Frames ein, so geht es dann im Prinzip wie bei klassischem Machine-Learning weiter.

Zu AAF: nachdem ich Dir hier das Ohr abgekaut hatte, war ich dann noch neugierig und habe etwas geschaut. Tatsächlich gibt es sowohl Python, als auch C++ Tools, die die öffnen und dumpen können (und mehr, aber das ist ja erst mal das Wichtigste). Ich habe dann daheim fix eine kontrollierte Timeline aufgesetzt und als AAF exportiert, der Dump war aber ernüchternd. Erstens wurde der Retime nicht mal erwähnt, zweitens war sogar der In-Punkt falsch; komplett unverständlicher Offset von irgendwie 43 Frames. Irgendwann kam ich dann mal auf die Idee, die AAF nochmal in Resolve zu importieren (war spät): tja, der Dump war komplett korrekt. Nicht nur hat Resolve keinen Retime in die Datei geschrieben, der In-Punkt ist tatsächlich genau so (falsch) drin, wie er im Dump steht. Ernüchternd, aber immerhin ein kurzes Abenteuer :)

Beste Grüße