Beiträge von SYHT

Das sagt mir, dass Du es besser weist ;O)

Die Unterhaltung ist hiermit beendet!

@Achilles

Lasst es mich mal so zusammenfassen: Wer um Himmels Willen ist Mario Aurich?

Und warum soll ich SLOG3 mit dem D-LOG M einer DJI OSMO Pocket 3 vergleichen? Da hinkt etwas gewaltig.

Außerdem schrieb ich bereits: "...wenn man solche Formate einsetzt, dann sollte man auch wissen warum"

Und ganz ehrlich will ich mich jetzt nicht zu dem "Mario Aurich-Betrag" äußern, denn es gibt doch viel zu viele Unbekannte und das vor allem auch zur Umsetzung in der Post (wie er selbst meint: "Ja, das Video wäre normalerweise nicht final bearbeitet." Ich kann zu solchen Beiträgen immer wieder nur den Kopf schütteln. Was soll das bringen?

Naja, ich meine mal, jeder wie er mag oder KANN ;O)

Zitat von Achilles

Zu Erinnerung:

S-Log, C-Log, V-Log (movie-college.de)

Wenn Du mit "zur Erinnerung" meinst, dass LOG nicht immer perfekt ist: Naja, dann zählt dies für mich zum Grundwissen, denn wenn man solche Formate einsetzt, dann sollte man auch wissen warum ;O)

Zitat von Hans-Jürgen

Der Hype kühlt wohl etwas ab, weil man mit immer mehr Kameras in RAW filmen kann.

RAW - klar, aber dann sollte man auch den Speicherhunger berücksichtigen und die Datenverarbeitungskette im Nachgang.

Im Moment erspare ich mir das mit LOG und habe mit h265 und 200MBit genügend Reserven - für meine Anwendungsfall als "Normalverbraucher". Der Gag an LOG ist halt die Reserve gepaart mit Speicherersparnis.

Zitat von Achilles

Log-Formate sind zeitweise sehr begehrenswert geworden.
Diese "Hype" ist aber mittlerweile abgekühlt, weil man draufgekommen ist,
dass man die korrekte Belichtung nicht unbedingt leicht realisieren kann.

Als Hype sehe ich LOG nicht, denn die Formate zeichnen einfach die höchste erreichbare Dynamic auf und eine korrekte Belichtung ist nun nicht wirklich so schwer. Ein gewisses Grundwissen muss man halt voraussetzen und ist halt für den "Nebenbeifilmer" nicht so leicht zu durchschauen. Aber diese haben dann Rec709 und Rec2020/2100(HLG/HDR).

Zitat von gurlt

Wenn nicht ständig jemand was Neues erfinden würde…

Nein, Du hast ja durchaus recht.

Nur sehe ich es eher als unwahrscheinlich an, dass die USA etwas an ihrer Strom- oder TV-Technik verändern wird. Die hängen ja auch in anderen Dingen an ihren „Traditionen“. Selbst die Woche beginnt da ja an einem anderen Tag.

Wie gesagt, ist es inzwischen auch schon dadurch leichter geworden, weil heute die modernen Geräte eigentlich mit allen Normen klarkommen.

Nur halt einige Smartphones und ähnliche Geräte sind da von den Möglichkeiten her eingeschränkt. Was halt meist eine Entscheidung der Hersteller aus Kostengründen sein dürfe.

Früher waren die Probleme jedenfalls größer, wenn man es aus irgendwelchen Gründen mit einer abweichenden Technologie zu tun bekam.

Und es gibt halt auch wenige wirkliche Gründe sich für eine für den eigenen Bereich „abweichende“ Norm zu entscheiden. Oft wird sowas nur von irgendwelchen „Experten“ propagiert, die sich damit hervorheben wollen und die eigentlichen Zusammenhänge nicht kennen.

Alles anzeigen

Ja, diese Erfindungen müssen aufhören - das Rad ist ja schon erfunden, dass muss reichen ;O)

Oh, diese Ammis. Naja, aber zumindest alte Zöpfe (krumme fps) könnte man leicht abschneiden und es gibt ja bereits große Aufschreie (Filmemacher, aber auch Apple).

Aber wie schon gesagt: 24/25/30 und die Vielfachen - und die Welt wäre perfekt.

Zitat von wolfgang

Log ist doch schwer ok. Da gibt es auch mehrere verschiedene - nur wem kümmert es?

Vorrangig ging es mir ja um die fps - aber du hast Recht, ich habe die Normen an sich auch angeführt.

Das sind aber wieder "Normen" die jeder Hersteller für sich erfunden hat - also eigentlich doch keine Norm, sondern ein herstellereigener Produktionsprozess.
Dies bekommt man jedoch mit den jeweiligen LUTs sofort und ohne großartigen Aufwand perfekt in den Griff. Anders als den fps-Wirwar ;O)

Grundsätzlich, aber vielleicht sollte man dann doch mal Überholte abschaffen und sich auf einen Nenner einigen.

Hinsichtlich fps wäre das in meinen Augen 24/25/30 und die Vielfachen davon - UND das die komplette Kette - also von der Aufnahme bis zu Widergabe (auch PC-Handy-Monitore). Die Welt könnte so einfach sein.

Naja, da filme ich eigentlich SLOG und AppleLOG.

Außer wieder bei den Billigheimern ;O) bzw. bei der Insta360-App.

Es gibt so viele Baustellen und schön das wir so viele Normen haben, denn damit kann man so richtig gegeneinander arbeiten.

So, nun habe ich es verstanden, zumindest gehe ich davon aus ;O)

Das 59,94 DF Material sind tatsächlich 59,94 - WOBEI, KEINE Kamera 59,94 Bilder aufzeichnen kann, sondern letztlich doch 60p aufnimmt, aber der Timecode die Richtung weißt.

Letztlich spielen VLC, MPC, MP & Co. die 59,94 als 60p ab und damit NICHT korrekt. Das hat mich komplett in die Irre geführt.

Alle Cams (a7SIII, AcePro, DJI Mini) zeichnen durch die Bank 59,94 fps auf. Geprüft in den entsprechenden Projekten (also 23,94/24/25/29,97/30/50/59,94/60-Material in gleichen und unterschiedlichen Timelines) mit einem ordentlichen "Dreher" um die eigene Achse -> nur so kann man die Bildanzahl prüfen. (Jetzt ist mir schlecht)

Auf dem iPhone könnte ich über die BM-App die 59,94 erreichen und damit würde theoretisch alles zusammen.

Aber leider: Die Insta360-App nutzt die Frameraten des iPhone und lässt sich nicht davon abbringen. Diese App möchte ich aber gern nutzen, da nur diese mir das Tracking per Markierung zulässt.

Im Ergebnis: Die Ammis sollten Ihren alten NTSC-Standard so langsam mal aufgeben und glatte Frameraten einführen/akzeptieren. Technisch ist dieser Standard völlig veraltet und nicht mehr notwendig. Auch die Petition der Filmemacher wurde bisher nicht erhört.

Ich für meinen Teil werde weiter in 25/50p filmen, so wie theoretisch 3/4 der Welt.

Fasst hätte es die kleine Minderheit (30/60/NTSC) mit ihrem Durcheinander geschafft mich davon abzuhalten und das nur aus der Überlegung der PC-Bildschirme heraus.

Warum die großen Konzerne es nicht einfach den Regionen überlassen in 25/50 bzw. 24/30/60 zu filmen UND zu SCHAUEN. Es ist doch eigentlich finster, dass man heute noch immer die Masse mit reinen 59,94 Hz - Bildschirmen abspeist. Technisch kein Problem und sicher keinen Cent teurer, aber NÖ, Stur und Marketing (für däml....) Und dann kommt noch das iPhone, die es zwar verstanden haben, aber leider auch keine Alternative anbieten. Und so ruckelt der ganze 30/60/NTSC-Welt sicher noch die nächsten 100 Jahre fleißig vor sich hin.

Apple hat es also verstanden, steht jedoch ganz allein da. Und wenn man es schon verstanden hat, dann führt man VFR ein - ich geh am Stock! Setzen 6!

Bloß gut, dass wir im PAL-Land und dem eigentlich viel größeren Weltanteil, immer noch unsere guten 25/50p haben.

Für mich ist das Thema (der Ausflug und Ausrutscher zu 30/60/NTSC) damit schon wieder vom Tisch.

Einzig nervt mich der Umstand, dass die Masse vor Billig-Monitoren mit lediglich 59,94 Hz sitzt und sich dann bei mir beschwert wenn es ruckelt. Versuche das denen mal zu erklären.

Das Thema ist schon für uns Filmer nicht ganz einleuchtend - wie soll man das dem Ottonormalverbraucher beibringen. Gar nicht, denn ich sehe die Konzerne in der PFLICHT diese Schei... zu beenden und es wäre auch nicht zu viel verlangt wenn man schon "großkotzig" PAL-Formate zulässt, auch das doppelte von 25 rüberzureichen. (60 schafft man, aber 50 ist nicht nachvollziehbar??? - das ist einfache Mathematik und Double-PAL ist mittlerweile kein Exot mehr ;O) )

So, dass musste mal sein und ich hoffe auch andere würden mal mitschreien und die Konzerne wecken. Denn wie kann es sein, dass wir Tausende auf den Tisch legen und dann so einen technischen Mist vorgelegt bekommen. Die Lösung wäre doch einfach alle Formate (fps) anzubieten und nicht das jeder sein eigenes Süppchen kocht und der Meinung ist, dass alle anderen doof sind, nur der eigene Weltkonzern die Weisheit mit Löffeln gefressen hat.

(Und ehe mir wer zuvorkommt: Ja PAL und 25/50 sind zwei Paar Schuhe - aber mir geht es hierbei rein um die fps und die sind nun mal schon seit TV-Beginn im PAL-Land 25 (50))

@gurtl: Mir ist das grundsätzlich alles klar, aber wie erklärst Du dann die in #52 eingefügte Tabelle. Eine a7SIII hat KEINE VFR und auch eine DJI mini Pro nicht. Wenn diese also in 59,94 aufnehmen, dann müssten doch die Zeiten im 59,94-Proket stimmen, aber sie stimmen ebend erst im 60p-Projekt.

Übrigens:

Egal welche "glatte" Projektframerate (24p, 25p, 30p, 50p, 60p) ich wähle, Resolve importiert das Files immer mit der korrekten Länge.

Dann läge es an mir zu sagen, in wie weit ich gern Frames behalte/verwerfe - durch entsprechende prozentuale Angleichung und das Akzeptieren von Beschleunigung/Verlangsamung.

Aber sobald ich die reinen NTSC-Formate (...,94 / ...,97) nutze, unterscheidet sich die Länge in der Timeline.

Dennoch: Was machen die Kameras, also was geben die nun tatsächlich aus? Hmm.

Angegeben kann ja sein die Abspielframerate oder die Record-Framerate. Wie bekomme ich das heraus?

Ich dreh mich im Kreis ;O)

OK, also mit dem Artikel Teil 3 (Achilles) verstehe ich nun wie ich in Resolve die Resampling-Einstellungen (im Vergleich zu Vegas) bewerkstelligen kann. Damit kann ich die technischen Hürden lösen.

Nun müsste ich nur noch wie vor beschrieben verstehen, was die Kameras tatsächlich aufzeichnen und warm die Längen der 59,94-Files in einem 59,94-Projekt nicht korrekt sind. Oder werden doch 60p aufgenommen (DF) und 59,94p angegeben (aber scheinbar durch die Bank weg),

Vielleicht könnten das DJI Mini 3 Nutzer und a7SIII-Nutzer nachvollzeihen?

@Achilles: Danke für den interessanten Artikel zu Resolve und Frameraten - ich habe aber erst die Teile 1 und 2 durch, 3 bis 5 muss ich noch.

@gurlt: Auch Dir Danke für deine ausführlichen Ausführungen. Das entstehen der NTSC-Formate war mir bereits bekannt, nur habe ich bisher immer in 25/50p gefilmt und solche Problem nicht gehabt.

Grundsätzlich ist mir klar, wie Frameraten zu verwenden sind, aber was die Kameras ebend so machen ist mir nach wie vor ein Rätzel.

Begründung:

Ich habe hier 4 Kameras, die wie folgt aufnehmen:

- a7SIII: 59,94 DF

- Insta AcePro: 59,94

- iPhone 15 Pro Max: 59,94 (MediaInfo) bzw. 60 (Resolve)

- DJI Mini 3 Pro: 59,94

Nun habe ich mit Achilles verlinkten Artikel gelernt:

"- Die FPS ist die Wiedergabe-Bildrate, nicht die aufgenommene Bildrate

- Die FPS ist die aufgezeichnete Bildrate

- Die FPS sind ein variabler Satz, z. B. wenn Sie Kamera-, Handy- oder Bildschirmaufnahmen verwenden"

Nur wie will ich das ernsthaft prüfen, wenn mir die Programme unterschiedliche Infos liefern. MediaInfo vertraue ich da schon, aber in der beigefügten Tabelle sieht man, das eigentlich alle 59,94 fps-Files einzig in einem 60p-Projekt mit korrekter Länge wiedergegeben werden.

Tabelle2.png

(Die SOLL-Zeiten sind in Millisekunden (100) gerechnet und so entsprechen 25 ms den IST-"Zeiten" von 15 Bildern in Resolve)

Auch das iPhone Material (selbst aus der BM-App) wird als 59,94-Material interpretiert und im Projekt korrekt als 60p eingespielt.

Beim Material der a7SIII habe ich ja noch die Erklärung auf Grund des Zusatzes DF (Drop Frames).

Modus der Bildwiederholungsrate : konstant

Bildwiederholungsrate : 59,940 (60000/1001) FPS

Die (60000/1001) sagt mir, dass volle 60p aufgenommen werden, aber in einem 59,94-Projekt 0,1% verlangsamt werden per DF. Ist das korrekt?

DF:

"Die Angabe “DF” hinter der Framerate 59,94 steht für “Drop Frame”. Dies ist ein spezielles Timecode-Format, das verwendet wird, um die leichte Diskrepanz zwischen der tatsächlichen Bildrate und der nominalen Bildrate zu korrigieren.

Bei der Framerate von 59,94 Bildern pro Sekunde handelt es sich um eine leicht reduzierte Version der 60 fps, die ursprünglich für das analoge Fernsehen entwickelt wurde. Um sicherzustellen, dass der Timecode mit der tatsächlichen Echtzeit synchron bleibt, werden bei der Drop Frame-Methode bestimmte Frames übersprungen (oder “gedroppt”). Dies geschieht, um die kumulative Zeitdifferenz zu korrigieren, die sich sonst über längere Zeiträume hinweg aufbauen würde."

Nun die ganz große Frage: Wie bekomme ich heraus, welche FR die Kameras tatsächlich aufzeichnen, denn die reinen Zahlen aus MediaInfo stimmen scheinbar (siehe Tabelle oben) nicht mit den tatsächlichen Laufzeiten, die Resolve aber korrekt interpretiert, überein. Oder habe ich einen Denkfehler?

Oder wird der fertige 29,97 / 59,94 Film am TV einfach mit dem Faktor 0,999 abgespielt?

Tabelle.pngHallo an Euch Beide und Danke für Eure Ausführungen.

Das dass iPhone mit VFR arbeitet war mir schon soweit klar, aber woher die unterschiedlichen Interpretationen von MediaInfo bzw. Resolve (oder auch Windows-Explorer) kommen, das bleibt mir ein Rätzel.

Interessant ist ja auch, das alle Kameras saubere 25/50/100 fps liefern, Nur bei den US/...-Formaten einige Ausreiser vorhanden sind. So werden tatsächlich falsche 60p angegeben und eigentlich bei allen durch die Bank 59,94 sauber ausgegeben, nur eben bei iPhone wird man nicht schlau.

Innerhalb der Blackmagic Camrea App kann ich alle erdenklichen fps einstellen und Resolve selbst gibt mir das auch korrekt so an, nur MediaInfo ist da wieder anderer Meinung- was ist nun richtig?

Aber auch hier: Nur die Pal-Formate (auf fps bezogen) liefern feste Zahlen (ja, auch mit der BM-App gurlt), der ganze US/...-Mist bleibt variabel und liefert es unverständlich.

Die 59,94 bzw. 60 wollte ich eigentlich nutzen um es für die PC-Bildschirme entsprechend aufzuarbeiten, da der Film nicht im/auf TV laufen soll. Also unabhängig was YouTube alles an fps nimmt, so sollten die Probleme der PC- und Handy-Bildschirme vermieden werden. So zumindest der erste Gedanke.

Wenn ich das alles so betrachte, einschl. der Probleme bei Kunstlicht, dann lässt es mich doch schon wieder zu 50p tendieren.

Was mich gereizt hätte, wäre halt noch das Tracking der Insta360 App, welche leider nicht mit 50p zurechtkommt.

Was ich mich bei dem ganzen "Mist" frage, wie der Rest der Welt mit diesen krummen NTSC (fps) zurecht kommt und warum jeder Hersteller hier sein eigenes Süppchen kocht, so ganz in dem Sinne: Jeder ist schlauer als der Andere.

Ich melde mich nach langer (krankheitsbedingter) Abstinenz mal wieder zurück und rufe damit ein Hallo in die Runde.

Wie würdet Ihr in Resolve Material mit 59,94 fps und 60 fps mischen?

Leider nehmen die Kameras alle unterschiedlich auf und es ist kein gemeinsamer Nenner zu finden. 25p/50p mal ausgeschlossen, da es explizit für YouTube und Co. sein soll.

Gibt es in Resolve eine "schlaue" Einstellung (Auswahl einer Interpretationsmöglichkeit) dazu? Also ich meine so etwas wie das Resampling (an/aus) in Vegas oder wie oben diskutiert in Edius (wirklich NUR für 59,94 und 60).

3POINT: Der ShutterEncoder ist echt Gold wert. Aber wenn es innerhalb Resolve eine Funktion dazu gäbe, dann würde ich mir gern diesen Schritt sparen. Außerdem habe ich dazu noch immer ein Verständnisproblem. (siehe nachfolgend)

Was ich aber noch nicht so recht verstehe:

Unter den Kameras ist auch Material von einem iPhone 15 Pro Max.

Windows-Explorer (Details) interpretiert dazu:

59,96 fps

MediaInfo interpretiert dazu:

Modus der Bildwiederholungsrate : variabel

Bildwiederholungsrate : 59,940 (59940/1000) FPS

minimale Bildwiederholungsrate : 54,545 FPS

maximale Bildwiederholungsrate : 66,667 FPS

Resolve interpretiert dazu:

Shot Frame Rate: 60p

Start-TC: 00:00:00:00

End-TC: 01:02:18:52

Frames: 224432

Die 224432 Frames müssten in einem 60p-Projekt rechnerisch eigentlich einen TC von 01:02:20:32 ergeben.

Erreicht werden aber die angegebenen 01:02:18:52.

In einem 59,94 fps-Projekt erreicht der Clip einen TC von 01:02:15:07.

Beide Clips (also einmal im Original und einmal mit ShutterEncoder "behandelt") erreichen im gleichen Projekt (59,94 und 60) exakt die selbe Länge. Also Resolve veranstaltet da bereits etwas mit dem Material? Nur was und wo kann man das ggf. beeinflussen?

Auch sagen alle Programme (Windows-Explorer, MediaInfo und Resolve) genau das Gleiche nachdem ich den Clip durch den ShutterEncoder laufen lassen habe.

So richtig schlau werde ich aus den iPhone-Clips nicht.

Welche Framerate liefert das iPhone denn nun tatsächlich. Habt Ihr dafür ggf. eine Antwort?

Hallo zusammen,

diese Frage stellt sich mir, da Resolve ein doch merkwürdiges Verhalten an den Tag legt.

Fall 1:

Ich habe mehrere Video-Spuren (10). Auf der untersten liegen die eigentlichen Takes. Auf den darüber liegenden Spuren verteilen sich verschiedenste Fusion-Compositions.

Spiele ich die Vorschau ab, dann spielt es dies wie erwartet ab.

Schalte ich jetzt aber z.B. Spur V5 bis V10 ab (Disable), dann zeigt mir Resolve dennoch flickerartig Segmente dieser Spuren in der Vorschau.

Fall 2:

Ich habe genau 3 Takes aus einer einzigen Kamera (mit den gleichen Einstellungen) in der Timeline in Spur V1.

Das erste und das dritte Take verhalten sich ganz normal. Das zweite Take bekommt jedoch auch wieder flickerartig Teile der Takes eins und drei beigemischt.

Tausche ich nun das Take zwei gegen irgendein anderes Take/Bild/..., dann spielt Resolve die Vorschau wieder einwandfrei ab.

Für beiden Fälle:

Dieses Verhalten bleibt sowohl mit Proxys als auch ohne Proxys, sowohl mit Full/Half/Quarter-Resolution, mit und ohne Rendercache und auch bei komplett gelöschtem Rendercache bestehen.

AUCH im Renderergebnis, also im finalen Produkt, ist dieser Fehler anzutreffen.

UND auch ein Kollege hat gleiches Verhalten schon feststellen können - nicht immer, aber immer wieder.

Damit auch: Die Projekte wurden auf 3 verschiedenen Rechnern mit komplett unterschiedlicher Hardware getestet.

Da stellt sich mir die Frage, ob dies auch der Grund für dieses Dilemma ist:

Resolve 18 stürzt beim Rendern dauernd ab - GPU abschalten?

(Post #35)

Kann die Probleme irgendwer nachvollziehen/bestätigen? (Außer mein Kollege ;O) )

DANKE

Naja, ich schneide mit Version 18.1 und könnte maximal zu Version 18 zurück, was ich mir damit sparen würde.

Ich habe nun noch ein anderes Problem:

Die Bilddatei einer "Papierrolle" (.png, 1456 x 15300 Pixel = 35 MB) wird innerhalb Fusion im 3D-Raum mit einer Kamera "abgefahren".

Das Ergebnis (nur Ausschnitt) könnt ihr hier sehen: https://youtu.be/X-pcxJaMrzs

Warum "zerreist" es mir die Bilddatei optisch so? Ich meine damit das "Geflacker" am oberen Bildrand oder auch an der "Ende"-Schrift - da sieht man es zumindest am Besten.

Oder sollte man in Fusion nicht die Kamera für das Abfahren dieser Papierrolle nehmen - wobei auch die reine Animation über die Y-Achse der Bilddatei gleiches Problem auftritt.

Du meinst ich soll eine ältere DR-Version aufspielen? Oder das Projekt?

Ich habe nun etwas gefunden woran es liegen könnte. Es ist eine nested Timeline mit GoPro-Files mit Flicker-Filter und NR.

Das blöde ist, ich hatte noch eine alte Version (1.x) von FlickerFree getestet und die aus versehen vorher (vor DR DeFlicker) nicht wieder rausgeschmissen. Nun haben zwei DeFlicker gearbeitet und das ggf. "gegeneinander".

immer wenn ich jetzt über das File (Timeline) ging, kam die im Anhang beigefügte Fehlermeldung. nur finden muss man das bei der Projektlänge von etwa 1 1/2 Stunden erstmal.

Ob es daran lag werden die nächsten Tests zeigen.