CameraRick hat geschrieben:
Das Speichern dauert bei mir ca 5 Sekunden, ist also nix was mich wirklich ausbremst.
Das geht mit einem einzigen SD-Clip noch schneller...
Mußt schon genauer schreiben um welches Timeline-Material es geht und welche Timeleinelast drauf ist!
** S8-Hobbyfilmer seit 1970, Video seit 1988, Schmalfilmdigitalisierer seit 2007 **
** Aktuelle Hauptkameras: Sony ZV-1 & Zhiyun Crane M2 Gimbal plus DJI Pocket 2 Gimbal-Kamera** http://www.videoundbild.de/
das problem beim scheiden sind einfach die verhältnismäßig schlechte reaktionszeiten des programms. andere anwendungen regieren auf gleicher hardware einfach flüssiger, was für guten schnitt ausgesprochen wertvoll ist.
die probleme beim speichern, speziell die gelegentlichen abstürze während des autromatischen zwischensicherns, würde ich übrigens nicht mit verwendung von datenbanken in verbindung bringen. sowohl die PostgreSQL basierte variante, wie auch die XML file baserende, sind an sich zuverlässig und schnell. das problem liegt vielmehr darin, dass resolve jede menge binärinformation in die entsprechenden dateien/tabellen packt. die damit verbundenen probleme dürften also vielmehr von der dafür notwendigen serialisierung von internen zuständen bzw. datenobjekten stammen. diese eigenheit ist auch der grund dafür, warum kein einziges anders programm in der lage ist, resolve projektinformationen in der ursprünglichen form zu importieren od. sinnvoll auszuwerten. derartiges ist nur über den umweg anderer formate und all den damit verbundenen informationsverlusten möglich.
mash_gh4 hat geschrieben:
das wirkliche problem mit avisynth ist eher die 8bit herkunft, die heute leider sehr viele historisch gewachsene plugins im professionellen umfeld als völlig unzureichemd erscheinen lässt.
Vapoursynth ist nicht mehr 8 Bit, sondern kann alles:
Pixel data types: 8-–12-, 14- and 16-bit integer, 32-bit float
rudi hat geschrieben:Vapoursynth ist nicht mehr 8 Bit, sondern kann alles:
Pixel data types: 8-–12-, 14- and 16-bit integer, 32-bit float
Meiner Meinung total unterschätztes Programm.
genau! -- nur sind halt leider sehr viele altbestände aus dem avisynth umfeld diesbezüglich deutlich problematischer... aber grundsätzlich teile ich natürlich deine einschätzung.
übrigens können vapoursynth scripts mittlerweile auch aus dem mpv heraus genutzt werden.
Frank Glencairn hat geschrieben:
Wenn man einen Rechner hat, der halbwegs innerhalb der Spezifikationen für Resolve ist, sind auch große Projekte überhaupt kein Problem (da werden ganze Hollywood Blockbuster drauf geschnitten). Das Speichern dauert bei mir ca 5 Sekunden, ist also nix was mich wirklich ausbremst.
Welche Hollywoodfilme werden denn darauf geschnitten?
Ich speicher hier gerade ein recht großes 4K Projekt und warte gerne mal 20sek, das ist halt einfach nicht tragbar. Datenbank liegt auf einem Speicher der runde 2GB/s schreibt und liest.
Dazu kommen dann halt die Anpassbarkeit der Fenster, Flexibilität mit Projektdaten... generell "Fexibilität" ist vermutlich ein gutes Stichwort - wer alles an einer Maschine machen kann oder muss und die Fensteraufteilung etc mag, dem kann das natürlich egal sein. Schnitt und Grading will ich halt ungern an einer Maschine haben.
diese eigenheit ist auch der grund dafür, warum kein einziges anders programm in der lage ist, resolve projektinformationen in der ursprünglichen form zu importieren od. sinnvoll auszuwerten. derartiges ist nur über den umweg anderer formate und all den damit verbundenen informationsverlusten möglich.
Aus welchen Programmen kommt man denn, mit allen Settings etc, verlustfrei wo hin? Und auf welche Art und Weise? XML und/oder AAF brauchen sie doch alle.
Dass AviSynth nur 8bit kann war mir nicht bekannt, das grätscht es für mich natürlich auch ins Aus. Von VapourSynth habe ich noch nie gehört, aber kann anscheinend auch nur Windows. Schade drum!
CameraRick hat geschrieben:Aus welchen Programmen kommt man denn, mit allen Settings etc, verlustfrei wo hin? Und auf welche Art und Weise? XML und/oder AAF brauchen sie doch alle.
praktisch alle wirklich großen und markbestimmimenden schnittsystem-anbieter haben bewirkt, dass ihre jeweils genutzten formate dokumentiert und über kurz oder lang zum defacto standard für den austausch wurden.
grass valley -> EDL
avid -> AAF
FCP u FCP X -> XML
CameraRick hat geschrieben:Von VapourSynth habe ich noch nie gehört, aber kann anscheinend auch nur Windows. Schade drum!
steht doch eh schon ausdrücklich da, dass das NICHT der fall ist!
wie gesagt, ich nutze es regelmäßig unter linux.
CameraRick hat geschrieben: Von VapourSynth habe ich noch nie gehört, aber kann anscheinend auch nur Windows. Schade drum!
Nein, VapourSynth läuft so ziemlich überall (Win, Mac, Linux).
Wird dir trotzdem nicht taugen, weil man da alles von Hand in Python scriptet. Damit gehen manche Sachen halt sehr elegant, andere dagegen eher umständlich. Schneiden geht z.B. über die Index-Fuktionen von Python Objekten, womit man den In- und Out Point mit zwei zahlen in einer Klammer festsetzt. Clips können im Script per "+" aneinandergehängt werden. usw. usw.
CameraRick hat geschrieben:Aus welchen Programmen kommt man denn, mit allen Settings etc, verlustfrei wo hin? Und auf welche Art und Weise? XML und/oder AAF brauchen sie doch alle.
praktisch alle wirklich großen und markbestimmimenden schnittsystem-anbieter haben bewirkt, dass ihre jeweils genutzten formate dokumentiert und über kurz oder lang zum defacto standard für den austausch wurden.
grass valley -> EDL
avid -> AAF
FCP u FCP X -> XML
Ok Du hättest auch einfach "nein" schreiben können, denn keines dieser Formate bringt alle Settings irgendwo rein. EDL kann außer lineare Timewraps erst mal gar nichts, eine AAF aus Avid bringt nicht mal flippings und floppings in die meisten Programme.
FCPX nutzt keine XML mehr sondern fcpxml, das ist schon mal ziemlich anders und kann auch nicht alles. XML ist da ähnlich wie AAF, bleibt einiges auf der Strecke (Timewarps aus Premiere etwa sind ein Graus, wie das bei FCP7 war weiß ich nicht mehr).
Und das ignoriert einfach mal vollkommen, dass Resolve jedes dieser Formate (EDL, XML, fcpxml, AAF) selber exportieren kann, also verstehe ich nicht inwiefern da DaVinci in irgendeiner Form anders sein sollte, als die anderen?
Du sagst ja selbst "derartiges ist nur über den umweg anderer formate und all den damit verbundenen informationsverlusten möglich." - die anderen machen das doch genau so, wo ist hier der Punkt wo Resolve sich unterscheidet?
bzgl VapourSynth:
Sorry hatte ich falsch verstanden! War nur auf der Website (und vermutlich war es sogar die falsche, wenn ich Rudis Link sehe) und sah nur Windows Binaries, da habe ich wohl dort zu schnell, und bei euren Posts zu langsam geschaltet :)
Aber ja, taugt mir auch nur bedingt. Am Ende des Tages lässt es sich so schwer in unseren Workflow einbinden; in den meisten Fällen muss ich auch ffmpeg komplett umschiffen, da das viel zu oft nicht so raus kommt, wie es rein ging :(
CameraRick hat geschrieben:Du hättest auch einfach "nein" schreiben können, denn keines dieser Formate bringt alle Settings irgendwo rein.
genau das ist das problem!
weil es bei der umwandlung eben immer derart große verluste gibt bzw. kein kleinster gemeinsamer nenner zu finden ist, haben sich jeweils die internen formate bzw. organisationsstrukturen der marktbeherrschenden programme zu unterschiedlichen zeiten durchgesetzt und fakten geschaffen, die all anderen nachzuahmen versucht haben.
ich würde in diesem zusammenhang das interne format vom resolve eher mit AAF bzw. der avid tradition in verbindung bringen. auch sie nutzen diese unguten binären ingredienzien exzessiv. wobei das im falle von AAF wenigstens ausreichend dokumentiert ist, wenn es schon in der anwendung auf unterschiedlichen systemen bzw. verfügbaren alternativen implementierungen nichts als probleme mit sich bringt.
die beiden FCP XML varianten sind diesbezüglich deutlich vorbildlicher, wesentlich einfacher zu handhaben und auch sehr gut dokumentiert. an ihnen kann man aber auch erkennen, dass es eben nicht nur reine austauschformate sind, sonder dass derartiges immer auch eine ganze menge grundsätzliches design der anwendung impliziert bzw. festschreibt. das lässt sich nicht ohne weiteres übersetzten od. für andere zwecke und anwendungen adaptieren. deshalb ist auch in diesem beiden formaten keine wirklich befriedigende lösung zu sehen, die als genereller standard für andere programme herangezogen werden könnte bzw. ausreichen würde.
resolve ist prinzipiell nicht schlecht, was den umgang mit fremden projektformaten betrifft. da es ursprünglich ein hoch spezialisiertes tool war, das auf eine reibungslose zusammenarbeit mit fremder software angewiesen war, hat das dort besser funktioniert bzw. mehr augenmerk erhalten als in vielen geschlosseneren gesamtlösungen. genau das ändert sich aber nun langsam. auch die fülle an neuen features und fähigkeiten wächst derart schnell, dass die import/export fähigkeiten immer weiter hinterher hinken.
das zentrale problem bleibt aber der umstand, dass über das intern genutzte format derart wenig bekant ist, dass praktisch keine ausweichmöglichkeiten exitieren, notfalls direkt darauf zurückzugreifen, wo die anderen verlustbehafteten methoden nicht mehr genügen.
Frank Glencairn hat geschrieben:[Pffft!
Richtige Männer schneiden in einem Hex Editor.
du wirst lachen, aber genau das tu ich gerade dieser tage wieder!
die firma zeiss nutzt nämlich in ihren planetriums-fulldome-projektionssytemen derart imkompatible MPEG2 formate, dass man sie wirklich nur mit dem hex editor bzw. auf dortigen einblicken aufbauenden selbst geschriebenen muxern nachzuahmen vermag. :(
und das ist leider keine einzelfall. mit genau solchen problemen schlag mich andauernd herum.
es gibt neben der schönen neuen ikea [wegwerf-]welt, die gewiss auch ihre tücken in der alltäglichen verwendung bzw. beim zusammenbau für viele mitmenschen auf lager haben mag, einfach noch immer richtiges handwerk, wo man ggf. auch aus massivem zirbenholz möbel zu fertigen versteht od. entsprechende kunstfertigkeit aus der hand von anderen zu restaurieren und an neue gegebenheiten anzupassen pflegt...
nur dann verstehe ich Deine vorherige Aussage nicht:
diese eigenheit ist auch der grund dafür, warum kein einziges anders programm in der lage ist, resolve projektinformationen in der ursprünglichen form zu importieren od. sinnvoll auszuwerten. derartiges ist nur über den umweg anderer formate und all den damit verbundenen informationsverlusten möglich.
Denn das gilt doch für alle Editoren, nicht exklusiv für DaVinci?
resolve ist prinzipiell nicht schlecht, was den umgang mit fremden projektformaten betrifft. da es ursprünglich ein hoch spezialisiertes tool war, das auf eine reibungslose zusammenarbeit mit fremder software angewiesen war, hat das dort besser funktioniert bzw. mehr augenmerk erhalten als in vielen geschlosseneren gesamtlösungen. genau das ändert sich aber nun langsam. auch die fülle an neuen features und fähigkeiten wächst derart schnell, dass die import/export fähigkeiten immer weiter hinterher hinken.
Die einzigen Programme die ich für den Conform besser finde als den Resolve sind NukeStudio und Smoke (beim Flame wird es ähnlich sein, da stecke ich zu wenig drin). Adobe ist hier ein Witz, bei FCP weiß ichs nun nicht.
Die wenigsten Programme bieten überhaupt ein gescheites Management für den Conform, und ich hab das Gefühl gerade Opensource Software hinkt hier noch weiter hinterher (das fängt beim TC an, der so gerne ignoriert wird).
Oder wo siehst Du hier die Schwachstellen, bzw die Stärken in anderen Softwares?
Verstehe mich bitte nicht falsch, aber ich habe ein paar Probleme manche Aussagen nachzuvollziehen, da sie für mich sehr im Kontrast stehen.
Python ist übrigens nicht so das Problem für mich, das beherrsche ich scho a weng :) da ich aber nicht in der Restauration tätig bin habe ich noch keinen Anwendungsfall gefunden, wo (irgendwas)Synth mir nun das bessere und/oder einfachere Ergebnis gebracht hätte, speziell in Anbetracht des Workflows. Vielleicht kenne ich da auch zu wenige Scripte, Denoising fand ich zB eben immer sehr ernüchternd, im Vergleich.
diese eigenheit ist auch der grund dafür, warum kein einziges anders programm in der lage ist, resolve projektinformationen in der ursprünglichen form zu importieren od. sinnvoll auszuwerten. derartiges ist nur über den umweg anderer formate und all den damit verbundenen informationsverlusten möglich.
Denn das gilt doch für alle Editoren, nicht exklusiv für DaVinci?
wieso? es gibt doch genug programme, die die beiden FCP projektformate tatsächlich zu nutzen verstehen, aber keines, das die schwarze magie der resolve datenrepräsentation richtig aufzulösen vermag.
aber ich glaube, wir reden da tatsächlich aneinander vorbei. ;)
CameraRick hat geschrieben:Die einzigen Programme die ich für den Conform besser finde als den Resolve sind NukeStudio und Smoke (beim Flame wird es ähnlich sein, da stecke ich zu wenig drin). Adobe ist hier ein Witz, bei FCP weiß ichs nun nicht.
ja, das würde ganz gleich wie du beurteilen! wobei es halt schon einen gewichtigen unterschied macht, wie gut sich das im nuke und smoke auch noch durch gute schnittstellen weiter an komplexe workflows anpassen lässt. dafür gibt es im resolve nichteinmal ansatzweise eingriffsmöglichkeiten. aber gut, dass braucht natürlich nicht unbedingt jeder.
CameraRick hat geschrieben:Die wenigsten Programme bieten überhaupt ein gescheites Management für den Conform, und ich hab das Gefühl gerade Opensource Software hinkt hier noch weiter hinterher (das fängt beim TC an, der so gerne ignoriert wird).
Oder wo siehst Du hier die Schwachstellen, bzw die Stärken in anderen Softwares?
auch in dieser beziehung würde ich mich deinem urteil weitestgehend anschließen.
ich halte es für eine katastrophe und den vielleicht einschränkendsten mangel praktisch aller frei software lösungen, dass sie in der frage des projektaustauschs derart weit hinten den praktischen erfordernissen zurück liegen. das ist ein horror!
trotzdem kann man von ihnen einiges lernen, das zumindest erklärt, warum diese sache so kompliziert und zugleich entscheidend ist. wenn man sich anschaut, wie viel mühen in den letzten jahren investiert wurden, um das editing framework im gstreamer von den elementarsten kinderkrankheiten zu befreien, findet man zwar leider noch keine wirklich brauchbare bessere alternative, die man bereits praktisch nützen könnte, aber doch sehr viel erhellendes über die damit verbundenen propleme. im falle vom resolve bleibt das immer ziemlich im dunklen, obwohl in wahrheit auch dort jede menge flickwerk vorzuliegen scheint.
du hast weiter oben das bsp. der retiming informationen bzw. deren austausch angesprochen. das ist ein ganz realistischer anwendungsfall. genau an diesem beispiel kann man aber auch sehr gut aufzeigen, wie eng die frage einer zuverlässigen internen datenrepräsentation und des betreffenden im-/exports zusammenhängt:
ich habe erst unlängst einen diesebzüglichen bug-report über ein ärgerliches problem im resolve verfasst. es dürfte sich wohl um einen objektiv reproduzierbareren fehler handeln, da das entsprechende schweigen auf seiten von BMD fast regelmäßig als diesbezügliche eingeständnis zu deuten ist, während man im gegenteiligen fall postwendend darauf aufmerksam gemacht wird, dass eine anwenderseitige fehlbedienung vorliegt. ;) jedenfalls ist auch dieser fehler vor allem deshalb ungut, weil man keinen einblick in die ursächliche interne repräsentation hat. genauso, wie man hier wieder nicht einfach auf irgendwelche praktikablen austauschformate zurückgreifen kann, um dem ganzen auszuweichen und das projekt schnell in einem anderen programm fertig zu stellen. retiming- und verschachtelungs-angaben sind eben diesbezüglich immer ganz besonders ungut. trotzdem, wenn man derartige möglichkeiten in einem programm anbietet, müssen sie einfach auch zuverlässig funktionieren! in diesem zusammenhang schadet es auch nicht, wenn die interne funktionsweise möglichst transparent und für jedermann prinzipiell nachvollziehbar und überprüfbar ist. damit können fehler klar erkannt und effektiv ausgemerzt werden. genau das macht meines erachtens nach auch wirklich gute und benutzerfreundliche professionelle werkzeuge aus. sich hier einfach nur mit einer hübschen oberfläche und klar abgesteckten grenzen der zugänglichkeit begnügen zu müssen, ist einfach nicht besonders zielführend oder hilfreich.
mash_gh4 hat geschrieben:
wieso? es gibt doch genug programme, die die beiden FCP projektformate tatsächlich zu nutzen verstehen, aber keines, das die schwarze magie der resolve datenrepräsentation richtig aufzulösen vermag.
Aber genau das war ja meine vorangehende Frage, welche Programme seine 1:1 Übersetzung von Projektdaten wirklich meistern können. Also aus welcher Quelle, und welches Ziel.
Darauf hattest Du mir XML/EDL/AAF Workflows genannt, was ja Blödsinn ist :o eine AAF von Avid nach Avid funktioniert zwar Bombe, aber ist ja keine andere Software. Eine XML von Premiere nach Premiere ist dagegen schon oft ein Trauerspiel *g*
ja, das würde ganz geleich wie du beurteilen! wobei es halt schon einen gewichtigen unterschied macht, wie gut sich das im nuke und smoke auch noch durch gute schnittstellen weiter an komplexe workflows anpassen lässt. dafür gibt es im resolve nichteinmal ansatzweise eingriffsmöglichkeiten. aber gut, dass braucht natürlich nicht unbedingt jeder.
Na gut, der Smoke ist hier aber auch nicht so richtig offen ;) das NukeStudio lässt sich natürlich durch Python und was nicht alles konfigurieren wie man will, das ist schon richtig, so etwas bietet Resolve auch nicht (und das ist uncool, wie die bescheidene Anpassbarkeit der Fenster), aber darum ging es hier ja nicht.
Im Rahmen der üblichen Conforming-Workflows á la EDL/XML/AAF ist Resolve deutlich potenter als die meisten Programme, was auch nicht so wundert da klassische Editoren auch nicht so richtig darauf ausgelegt sind. Das macht den Umstand im Resolve aber nicht schlechter.
ich halte es für eine katastrophe und den vielleicht einschränkendsten mangel praktisch aller frei software lösungen, dass sie in der frage des projektaustauschs derart weit hinten den praktischen erfordernissen zurück liegen. das ist ein horror!
Groß ist hier Natron... gibts im Bugtracker die Empfehlung für Metadaten/TC tools da die einfach fehlen, sagen die "dafür sind OFX Lösungen da". Dass einfach jede Software sein eigenes Management hat und es dafür keine OFX Tools gibt ist denen ja egal.... :) ich zumindest kann kein Programm professionell einsetzen, dass mir keinen Timecode im Material erhält
Deine übrigen Gedanken zu den OS-Softwares teile ich auch. Man darf es nicht zu sehr verteufeln, aber die Einstellung mancher Devs ist halt doch manchmal auch fragwürdig... :)
du hast weiter oben das bsp. der retiming informationen bzw. deren austausch angesprochen. das ist ein ganz realistischer anwendungsfall. genau an diesem beispiel kann man aber auch sehr gut aufzeigen, wie eng die frage einer zuverlässigen internen datenrepräsentation und des betreffenden im-/exports zusammenhängen [...]
Zu dem Thema eine kleine Anekdote: Retiming in Premiere.
Lineare Retimes in XMLs sind kein Thema. Nun hat Premiere die gleiche Art von Retime, die Resolve fürher hatte, wenn man nonlinear arbeiten will (Resolve hat mittlerweile eine weitere Möglichkeit drin, die ich selber präferiere). Wir hatten ein Projekt was auf Premiere geschnitten war und viele Retimings brauchte, aus div Gründen.
Nun hat diese XML aber nichts sinnvolles exportiert. Die einzige brauchbare Info aus der XML war, welcher Clip es gewesen ist - der Retime an sich wurde freilich nicht übernommen, aber nicht mal der Startframe, der ja hilfreich wäre; so bleibt die manuelle Suche. Sprich ich hab ggf einen 2min clip der 10sek verschnitten ist, und habe in der XML keine TC Info wann ich los muss. Das war eine Katastrophe. Die selbe XML in Premiere zurück importiert brachte das selbe Ergebnis.
Kann gut sein dass Premiere hier etwas zugelegt hat, habe es seit dem nicht mehr probiert (normalerweise wird am Avid geschnitten, wo Resolve die Retimes nahezu identisch übernimmt, zumindest gut genug fürs Grading).
Eine andere Sache hatte ich im NukeStudio, da hatte ich sogar regen Austausch mit dem Supportteam; ich hatte einen Film in dem praktisch jeder Clip lineare Retimes hatte, die passten auch ganz Ok aber ich musste noch ein wenig verfeinern (wir sind ja in der Online!). Weil ich aber alleine auf der gesamten Online eines 4-Min-Films saß und nur zwei Tage hatte, habe ich schmutzig arbeiten müssen, und einen TimeWarp oben drauf gelegt. Das sah in der Timeline toll aus, alles super, aber sobald ich gerendert habe war das Timing ein anderes, es wurde quasi der Retime-order vertauscht; in der Timeline erst Clip-Retime dann Timewarp, und vice versa im Export. So sollte man nicht arbeiten, aber manchmal muss man halt, und sie haben sich ran gemacht den Fehler zu beheben; ob ers schon ist, weiß ich tatsächlich nicht.
Das Problem mit Bugreports ist, die funktionieren nie so wie man will. Mein Lieblingsbeispiel ist der Nuke, habe ich glaub ich schon mal erzählt, wo ich händeringend auf einen Bug warte der vor Jahren reported wurde. Ich habe just die Adobe Suite auf meinem Laptop installiert und frage mich, wieso ich eine Woche vor 2017 immer noch nicht den beknackten Cloud-Folder in meiner Sidebar löschen kann, ohne in die Registry zu laufen (gibt auch keine aktuellen offiziellen Ansagen mehr dazu, aber immer noch Forenanfragen wieso das nach über einem Jahr nach dem Report nicht gelöst ist). Der Smoke hat mehr unbehobene Altlasten als ich mir merken kann, unsere Artists schmunzeln immer drüber und nutzen die selben Workarounds wie vor drei Jahren.
Immerhin hat BMD den 422 Bug ausgemerzt, sogar fixer als erwartet.
Was ich sagen will ist, jede Software hat ihre eigenen Probleme, BMD ist nur nicht sehr transparent. Aber die meisten anderen eben auch nicht - wenn Du so ein Retime-Problem mit Autodesk hat, was meinst Du wie das läuft? Das ist genau so verschlossen, nur der Service ist ein hunderstel besser, aber immer noch Mist.
Weil ich nicht in einer 1-Mann Firma arbeite wo man alles an einer Maschine lösen kann oder will.
Weil kein Editor den wir buchen können auf Resolve schneidet oder schneiden möchte.
Weil es unflexibel ist wenn Du mehr als ein Projekt parallel fährst.
Oder hast Du drei vollausgestattete Grading Suites?
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.
