Handy- und Cam-Dateien im Mix.

  • Hallo und so,


    ich habe so ein schönes altes Dickes Hilfe-Buch aus der Commodore Zeit mit dem großen Hinweis auf Seite 1
    „Never Change A Running System“. Wenn es auch aus technischer Sicht und Software sowieso Jahre nicht mehr benutzt wird,
    steht es als mahnendes Beispiel weiter in Sichtweite zu all meiner je besitzenden Computer + Software – und das waren einige viele!


    Die Warnung fast immer beherzigt und es zu meinem Anliegen der Erstellung eines Endproduktes eigentlich keinen großen Grund zum klagen gibt,
    stelle ich trotzdem meine Frage zu dem unterschiedlich vorhandenen Filmmaterial, die in einem



    Standard HD Projekt mit ES 1920 x 1080 50p mit lediger Änderung der Bitrate auf 10,



    zusammen soweit einwandfrei funktionieren, egal ob der anschließende Export erfolgte in:



    a) Datei ausgeben > H.264/AVC – für einen Multimediaplayer – oder


    b) Auf Datenträger brennen > mit div. Einstellungen während des Prozedere – für eine BD.




    Das vorliegende Material >


    Cam-Einstellung: AVCHD 1920 x 1080 50p >


    Ergebnis Filmmaterial: 1920 x 1080 - MTS 50p


    Handyeinstellung: 1920 x 1080 30p (ginge auch auf FBS 60p) >


    Ergebnis Filmmaterial 1920 x 1080 - mp4 30p (29.99)




    Unruhe gibt es lediglich in der Timeline bei Handy-Clips, obwohl Abhilfe geschaffen werden sollte aufgrund einer Info vor einiger Zeit mit:


    Maus rechts + Zeiteffekt > Halbbildoptionen > optischer Fluss auf jedem Clip aktivieren.


    Das brachte m.E. eigentlich nichts, und es müssen aber fast alle Handy-Clips, die Ton mäßig anfangen zu flattern, gerendert werden.




    Nun habe ich auch ein PG mit den „tollen“ Namen „Handbrake“ wo sich die FBS der Handydateien von 30 auf 50 in das meist genutzte
    Cam-Material ändern lassen. Daher meine Frage:




    a) Die aufgeführte Zeremonie beibehalten?


    b) Die 30p Daten mit Handbrake vor dem einlesen in Edius wandeln?


    c) Die Hände schön artig auf der Bettdecke lassen, mit Blick auf das besagte Buch?


    Oder?




    Danke schon mal im Voraus.




    dH

  • b) Die 30p Daten mit Handbrake vor dem einlesen in Edius wandeln?

    Einfach testen!

    HW: ASUS Z170-A; Proz: i7-6700K; RAM: 32 GB DDR4; GPU: RTX-3070, 8GB GDDR5; SSD: SAMSUNG-850-Pro, 500 GB
    SW: WIN-10/64 PRO (22H2-19045-2364), Firefox u.a.
    NLE: EDIUS-11.10.13903-WG; RESOLVE-18.6.6.0007 Studio

  • Hi,


    wie ich erst vor kurzem lernen musste, zeichnen Handys teilweise nicht mit den angegebenen 25 oder 30 p auf, sondern oft mit "variablen Frameraten". D.h. die Framerate der Aufnahme schwankt bei der Aufnahme je nach Inhalt zum Teil stark. Im Handy selbst wird das bei der Wiedergabe dann automatisch berücksichtigt. Auch einige Player sollen das wohl beherrschen. NLEs, auch Edius haben hier aber eher Probleme damit.


    Ob eine variable Framrate vorliegt kannst Du ggf. auch in Edius überprüfen. Wenn dort in den Clip-Eigenschaften "seltsamte" Werte, wie z.B. 21,35 p fps, auftauchen, handelt es sich darum.


    Möglich wären m.W. nach (auch bei nicht variabler Framerate):


    • Clip einfach ohne Veränderungen verwenden - da musst Du sehen was Edius da liefert;
    • Änderung der Eigenschaften auf eine "feste" Framerate mit möglichst geringer Abweichung zur angegebenen - also im o.a. 21,35 p Beispiel dann vielleicht 24p
      - hier ergibt sich aber eine Änderung der Geschwindigkeit;
    • Edius + Zeiteffekt - auch hier ändert sich die Geschwindigkeit und Du wirst um ein Rendern auch kaum umhinkommen;
    • Handbrake oder ähnliche Programme für die Umwandlung verwenden.


    Was jetzt für Dich das beste Ergebnis liefert hängt auch stark vom Bildinhalt ab.




    Den Ton kannst Du ggf. vom Bild "abkoppeln" (Gruppierung aufheben) um ihn durch eine Version ohne Verzerrungen zu ersetzen.



    Soweit meine mit Handyaufnahmen nur theoretischen Kenntnisse.



    Ach so - wichtig wäre natürlich auch, dass mit dem Handy "quer" gefilmt wird. Leider nehmen viele ihre Videos im "Hochformat" auf. Dann hast Du auch noch Probleme die entstehenden Ränder vernünftig zu füllen.


    Meine persönliche Meinung - den Stress tue ich mir erst gar nicht an.


    Gruß
    Peter

    ASUS Prime X299-A II, i9-10980XE, 64 GB, Nvidia RTX 2080Ti, BMD UltraStudio 4K Mini, RME Fireface 400, Win 11 Pro , EDIUS 11 WG

    Steinberg Cubase Pro, WaveLab Pro, SpectraLayers Pro

  • Maus rechts + Zeiteffekt > Halbbildoptionen > optischer Fluss auf jedem Clip aktivieren.

    Mein Vorschlag wäre in der hier angegebenen Option anstatt "Optischer Fluss" die Einstellungen "Bildvermischung" und "nächster Nachbar" zu testen.
    Wie Peter schon schreibt - es kommt immer auf den Bildinhalt an, welche Möglichkeit die besten Ergebnisse liefert. Man kann das nicht pauschal festlegen.


    Falls das Projekt noch nicht so weit gediehen ist, kannst du nach Tests und Erfahrung, welche der Einstellungen am besten passt diese Einstellung "Als Standard festlegen". Dann werden alle folgenden Clips, die du auf die Timeline legst gleich in dieser Einstellung berechnet und du musst nicht bei jedem einzelnen die Einstellung ändern.


    Gruß Uwe

    Edius 11 Pro, Rechner: Intel i9 9900K, 32 GB RAM, Asus Prime Z390-A ATX, Asus GeForce RTX2060 S, Win 10 Pro, 500 GB M.2 SSD, 4 TB HDD, 2x 27" UHD Monitor,ShuttlePRO v2, Adobe Lightroom, Affinity Photo, Affinity Designer

  • Erstmal Danke für alle Tipps – und dennoch drehe ich irgendwie am Rad!


    1. Rohmaterial ohne Änderungen beim Mix von 50p vom Camcorder und 30p vom Handy


    laufen beim Export in 264/AVC ohne irgendwelche Bild oder Tonstörungen.


    2. Erst bei einem Ablauf der Timeline, ändert sich der gelb/orange Balken in Rot,


    der Ton bei längeren Clips fängt an zu holpern, aber ein darauffolgender Export trotz Ton-


    Aussetzer keine Störungen verursacht.


    3. Werden die Clips egal ob mit „Nächster Nachbar“ oder „Bildvermischung“ bearbeitet,


    springt der Timelinebalken der 30p Clips auf Blau. Export – keine Probleme.


    4. Beim danach folgenden erneuten Abspielen der Timeline, werden von 5 x 30p Clips


    die vorher Blau waren, wieder Rot.




    Zur Anzeige des Pufferbalkens.


    zu. 2. Bei unbearbeiteten Clips beim Abspielen zeigt der Erste 16-20 > 500 an und die 4 folgenden


    Puffer 1/2 > 500 rot.


    zu. 3. Puffer 499 > 500




    Im Endeffekt ist es so, dass in diesem/meinen Fall beim Mix von 50p mit 30p zum Bildablauf eigentlich keine Probleme gibt, nur der Ton fängt an zu „spinnen“, was bei der Bearbeitung der Untermalung natürlich stört.


    Wenn es also so ist, dass lediglich der Ton der 30p Handyaufnahmen mit den oben erwähnten Filter bearbeitet werden müssen, kann ich mit Leben. Mit Hochkant Aufnahmen – so wie Peter schrieb – sicherlich auch nicht. Darüber habe ich schon mal eine Story verpasst:


    „Warum denn mit Handy filmen“


    was aufgrund gewisser Vorkommnisse – jedenfalls für mich – nicht umgänglich ist.




    Wenn es noch ein Hinweis gibt, erwarte ich diese gerne.


    Ansonsten bis sicherlich bald mal wieder.




    dH :thumbup:

  • 1. Rohmaterial ohne Änderungen beim Mix von 50p vom Camcorder und 30p vom Handy


    laufen beim Export in 264/AVC ohne irgendwelche Bild oder Tonstörungen.

    Das ist ja dann ok.


    2. Erst bei einem Ablauf der Timeline, ändert sich der gelb/orange Balken in Rot,


    der Ton bei längeren Clips fängt an zu holpern, aber ein darauffolgender Export trotz Ton-


    Aussetzer keine Störungen verursacht.

    Das ist klar - s. auch Angaben zum Puffer
    bei "Rot" sollten eigentlich auch die Bilder ruckeln, weil sich die Clips nicht flüssig abspielen lassen. Die "Tonprobleme" gibt es nur, weil die TL nicht flüssig abgespielt wird. Ter Ton selbst ist völlig in Ordnung.
    Einfach die Clips oder Sequenz/das Projekt auf der TL rendern. Dann sollte oben "grün" herrschen und sich alles flüssig abspielen lassen.

    3. Werden die Clips egal ob mit „Nächster Nachbar“ oder „Bildvermischung“ bearbeitet,


    springt der Timelinebalken der 30p Clips auf Blau. Export – keine Probleme.

    Dein Rechner ist ja auch recht vernünftig ausgestattet. Und QuickSync wird ja wohl aktiv sein.


    "Nächster Nachbar" oder "Bildvermischung" verwenden ja auch nur vorhandenes Material um die "fehlenden" Bilder zusammenzusetzen.
    "Optische Fluss" berechnet diese Bilder neu. Braucht also etwas mehr Ressourcen. Das Ergebnis ist stark abhängig vom Inhalt es kann besser aussehen als die beiden anderen, muss aber nicht. Das muss man im Ernstfall immer (notfalls für jeden Clip) austesten.



    4. Beim danach folgenden erneuten Abspielen der Timeline, werden von 5 x 30p Clips


    die vorher Blau waren, wieder Rot.

    Du meinst die Clips aus 3., ohne dass eine Veränderung stattfindet? - Das wundert mich, wenn es zuvor einwandfrei abgespielt worden ist.
    Aber auch hier sollte das Rendern der Sequenz = "Grün" helfen.

    Jede Bearbeitung, neue Filter auf den Clips usw. verändert natürlich die Situation. Dann muss neu gerendert werden. Kann natürlich nerven.



    Gruß
    Peter

    ASUS Prime X299-A II, i9-10980XE, 64 GB, Nvidia RTX 2080Ti, BMD UltraStudio 4K Mini, RME Fireface 400, Win 11 Pro , EDIUS 11 WG

    Steinberg Cubase Pro, WaveLab Pro, SpectraLayers Pro

  • Hallo Peter,




    soweit so gut verstanden. Ohne zu rendern kommt man bei den 30p Handy Clips die sich farblich verändern nicht rum, egal wie sie auch mit den Zeiteffekten/Halbbildoptionen bearbeitet wurden. Und so lang es sich nur um das ruckeln von Audioclips handelt, wäre es, wenn dies beim Bearbeiten nicht stört eh egal, weil beim Export das kpl. Projekt eh gerendert wird.




    Doch was ist mit Bildinhalt gemeint? Cliplänge, Clipbewegungen ect.?


    Die Abspielfehler tauchen ja nur bei den Audioclips auf. Ruckelnde Filmclips sind bis jetzt – ohne bei der Benutzung gewisser Effekte - noch nie aufgetaucht?




    Vielleicht noch eine Hilfe zur Überprüfung bzgl. des Hinweises der QuickSync Einstellung. Wie oder wo kann man dies Überprüfen?




    Gruß


    dH

  • Doch was ist mit Bildinhalt gemeint? Cliplänge, Clipbewegungen ect.?

    Mit Bildinhalt ist gemeint, was im Bild - also in dem aufgenommenen Clip - passiert.


    Z.B. die Aufnahme

    • einer regnerischen Landschaft ohne irgendwelche Personen oder Fahrzeuge - hier hast Du wenig Bewegung und eher wenig Kontrast;
    • am sonnigen Strand mit Badegästen, Booten, usw. - deutlich mehr Bewegung und teilweise hohe Kontraste;
    • Autorennen / Kirmesbesuch / Disco - sehr viel Bewegung, z.T. ganz andere Lichtverhältnisse, etc.

    Die Methode, die jetzt für den Clip aus 1. das beste Ergebnis bringt, kann für 2.+3. völlig falsch sein.Da muss man halt ausprobieren, was in welchem Fall das für einen verwertbare Ergebnis liefert - sowohl von der Methode (unbearbeitet, Zeiteffekt, Handbrake) ansich, als auch ggf. von Interpolationsmethode (nächster Nachbar/Bildvermischung/optischer Fluss) her.




    Die Abspielfehler tauchen ja nur bei den Audioclips auf. Ruckelnde Filmclips sind bis jetzt – ohne bei der Benutzung gewisser Effekte - noch nie aufgetaucht?

    Nein, das hat nichts mit dem Audio zu tun.


    Die Clips können wegen der zur Wiedergabe des Bildes notwendigen Berechnungen nicht in "Echtzeit" - also nicht flüssig mit 50 Bildern pro Sekunde - abgespielt werden. Das sagt ja auch der rote Balken oberhalb der Timeline und Deine Pufferanzeige aus.


    Wenn jetzt aber nur, sagen wir mal 10 Bilder abgespielt werden können, und dann die Wiedergabe kurz stoppt, dann muss natürlich auch der Ton unterbrochen werden. Dann kommen die nächsten 2 bis 3 Bilder mit synchronem Ton bis zur nächsten Unterbrechung, usw.
    Klar hört sich das dann wie ein Ruckeln im Ton an. Beim Export - egal in welches Format - wird ja gerendert, sodass dann der Clip flüssig abgespielt werden kann. Deshalb funktioniert es dann auch.


    Deshalb ja meine Aussage:

    Einfach die Clips oder Sequenz/das Projekt auf der TL rendern. Dann sollte oben "grün" herrschen und sich alles flüssig abspielen lassen.

    Ganz oben in Edius findest Du im Menü Rendern und in dem sich aufklappenden Fenster unterschiedliche Optionen, was gerendert werden soll.
    Da z.B. Sequenz rendern > geladenen Bereich rendern auswählen und Deine Sequenz sollte danach flüssig und ohne Aussetzer abgespielt werden können. Als Zeichen dafür wird der Balken oberhalb der Timeline grün.


    Wenn Du dann einen der Clips bearbeitest (z.B. schneidest, oder einen Filter darauf anwendest), muss natürlich neu gerendert werden, bevor er sich wieder einwandfrei abspielen lässt.




    Hinsichtlich der Überprüfung von Quicksync muss ich Dich leider an jemand anderen verweisen, da mein Rechner QS leider nicht kann.




    Gruß
    Peter

    ASUS Prime X299-A II, i9-10980XE, 64 GB, Nvidia RTX 2080Ti, BMD UltraStudio 4K Mini, RME Fireface 400, Win 11 Pro , EDIUS 11 WG

    Steinberg Cubase Pro, WaveLab Pro, SpectraLayers Pro

  • Hinsichtlich der Überprüfung von Quicksync muss ich Dich leider an jemand anderen verweisen

    Gerne:
    Ist relativ einfach - zwei Schritte:


    1) Prüfen, ob QS funktionieren sollte:
    Clip in TL > h.264-Export starten (F11 > h.264 wählen ...) < Prüfen, ob Häkchen bei "Use Hardware Encoder" gesetzt ist. Wenn JA: Dann sollte QS funktionieren.


    2) Prüfen, ob QS wirklich funktioniert:
    Z.B. 30 min Video in TL einmal mit und einmal ohne "Use Hardware Encoder" exportieren. Wenn der Zeitunterschied offensichtlich ist, dann funktioniert QS:
    - Ohne QS dauert der Export z.B. 60 bis 120 min (oder mehr),
    - mit QS dauert der Export etwa 15 min.
    // Man muss nicht die ganze Zeit des Exports abwarten, man sieht es an der angezeigten Restzeit auch, was da abläuft.
    Gruß kurt

    Bilder

    HW: ASUS Z170-A; Proz: i7-6700K; RAM: 32 GB DDR4; GPU: RTX-3070, 8GB GDDR5; SSD: SAMSUNG-850-Pro, 500 GB
    SW: WIN-10/64 PRO (22H2-19045-2364), Firefox u.a.
    NLE: EDIUS-11.10.13903-WG; RESOLVE-18.6.6.0007 Studio

  • So ähnlich hatte ich mir das mit den Bildinhalten auch vorgestellt. Nur tauchten dazu - bis auf die besagten Clips - wenig Problem auf. Vielleicht liegt es auch daran, dass die Aufnahmedauer der meisten Clips sich nicht ins unendliche ziehen.




    QuickSyn ist vorhanden. Denn das Testergebnis mit einem 3 Minuten Testprojekt mit Hardwarekodierung von 2 Minuten und ohne 3.30 Minuten sagt alles.




    Und dazu sage nicht nur Danke, sondern auch
    :jaMa: