Mavic Mini Testvideos (keine Bilder!)

ACHTUNG: Mit der neuen EU Drohnenverordnung muß sich jeder Drohnen-Betreiber beim Luftfahrtbundesamt registrieren und seine Drohne mit der e-ID kennzeichnen! Ein passendes Kennzeichen bekommst Du hier im Shop. Außerdem benötigst Du eine Drohnen-Versicherung. Hier geht es zu unserem Drohnen-Versicherungsvergleich. Informationen zum neuen EU Drohnenführerschein gibt es hier.

  • Umenaj schrieb:

    Konnte dann ca. 15 Minuten auf einem Feld kurz testen.

    Ist aber nicht gerade ein ausführliches Kennenlernen vor dem ersten Flug über Wasser ;)

    Umenaj schrieb:

    Hier ein neues Video. Dieses Mal mit 2,7k und 30 FPS.

    Hab es jetzt mal auf nem Rechner an der Uni angeschaut. Ist hier nur 1080p. Meine Videos (2.7k) werden aber auf YouTube, bzw auf dem Rechner/Browser hier richtig angezeigt - oder läuft hier doch was falsch?

  • Ahrimaan schrieb:

    ... Man braucht für die volle Qualität von 2.7 K eine Verarbeitungsrate von 45 MBits ...
    Kannst Du das mal näher erläutern? Bin gerade dabei mein ganzes Video-Know-how über Bord zu werfen!

    Bisher dachte ich mpeg ist eine Kompression, wo diverse, sich in bestimmten Zeitabständen (Anzahl von Bildern) ändernde Farbbereiche nach einem gewissen Algorithmus (je nach mpeg-Verfahren) zusammengefasst werden. Ähnlich wie bei jpeg im Fotobereich. Die volle Qualität liegt also nur bei Rohmaterial vor und das ist bei 2,7K 30 fps weitaus höher und würde eine standardmäßige microSD-Karte nach wenigen Sekunden sprengen.

    Je geringer die Datenrate bei einem mpeg basiertem System gibt nur an, wie stark das Roh-(Sensor-)-Material komprimiert oder anders herum, wie viele ähnliche (fast gleiche) Farben zusammengefasst und nach wie vielen Vectoren-Bilder (B-Frames) zwischen den jeweiligen Referenz-Bildern (I- bzw. P-Frames) liegt. Bei Vector-Bildern wird hier nur der sich ändernde Bereich erfasst, während bei Referenz-Bildern ein gesamtes neues Abbild gezogen wird.

    Gibt es also viele Verctor-Bilder zwischen den einzelnen Referenzen und werden dann noch große Farbbereiche zusammengefasstb, führt das bei schnell bewegten Bildern mit sich schnell ändernden, feinen Strukturen zu Unschärfen was als den oft zitierten Matsch oder auch „Pumpen“ zwischen unscharfen und scharfen Bildern, wahrgenommen wird.

    Mit LineSkipping oder PixelBinning hat das meines Wissens absolut nichts zu tun. Das sind verfahren (wenn die Prozessorleistung für ein Herunter-Rendern der Auflösung in Echtzeit nicht ausreicht) um eine höhere Sensorauflösung auf eine niedrigere Videoauflösung zu bringen. Hat zwar was mit Rechenpower aber nichts mit Datenrate zu tun. Es gibt tatsächlich Videos mit einer sehr geringen Datenrate die dennoch ein hervorragendes Bild wiedergeben. Das ist eine Frage des eingesetzten Kompressions-Codecs und der ist wiederum abhängig davon, welche Rechnerleistung bzw. welche Zeit zu berechnen zur Verfügung steht.

    Aber evtl. täusche ich mich auch und Du kannst uns erläutern wie Du auf die 45 Mbit/s kommst.

  • quadle schrieb:

    Ahrimaan schrieb:

    ... Man braucht für die volle Qualität von 2.7 K eine Verarbeitungsrate von 45 MBits ...
    Aber evtl. täusche ich mich auch und Du kannst uns erläutern wie Du auf die 45 Mbit/s kommst.
    Hi,

    eventuell täusche ich mich ja aber (ja ich tue es, 45 Mbit sind zu wenig):
    die 40Mbits sind die Containergrößen, die vom Prozessor berechneten Daten auf die SD zu schaufeln bzw zu verarbeiten.
    Dazu werden mehrer Mechanismen angewendet:

    Der Sensor wird mit 2K ausgelesen (Kann er wirklich nur 2K oder wird er 4K ausgelesen ? ich gehe von 4K mit Line Skipping aus, wenn jmd mal nen Teardown oder ne techn Doku hat kann er mich gerne korrigieren)
    Ich nehme aber den Referenzwert von 2,7K.
    Dieses ist eine Auflösung von 2704x1520x30 multipliziert mit 8 für speichern kommst du auf 97Mbits (Ich rede hier von einfach von Transferdaten zwischen Sensor und CPU) ! (Sorry 45 war definitv zu lasch für Rohdaten) Ich rede hier nur vom Speichern oder Verarbeiten in der CPU (Für Medizinische Aufnahmen errechnen wir so den Speicherbedarf zB für MRT Geräte)

    Nun kommt aber die Kompression dazu und der Verlust von Bilddaten die du nun treffend beschrieben hast.
    Nehmen wir eine Kompression von maximaler Güte erreichst du 2:1 was dann wiederum die 45 Mbits von mir erklärt.
    Egal wie die Kompression nun arbeitet, 45 wären das Minimum für meine Berechnung.

    Wenn dann noch so tricks wie Delta Berechnung dazu kommen (Siehe Mavic 1 Infraframe Flickering) , kann es noch weniger werden, darunter leidet aber die Qualität stark.

    Wobei ich mich gerade nun Frage worauf beziehen sich die 40Mbits , auf den Codec , auf die Transferrate von Sensor zu CPU ? oder Tranferrate zur SD Karte ?

  • Ahrimaan schrieb:

    Dieses ist eine Auflösung von 2704x1520x30 multipliziert mit 8 für speichern kommst du auf 97Mbits (Ich rede hier von einfach von Transferdaten zwischen Sensor und CPU) ! (Sorry 45 war definitv zu lasch für Rohdaten) Ich rede hier nur vom Speichern oder Verarbeiten in der CPU
    Jetzt wird es hier viel zu technisch, das wird erfahrungsgemäß hier niemanden wirklich interessieren, aber ich muss zur Richtigstellung kurz drauf eingehen. Abseits der Geeks also bitte überlesen. :)

    @Ahrimaan, Du schmeisst da etwas durcheinander und Deine Rechnung passt auch nicht. Zunächst mal, und auch nur nebenbei, werden vom Sensor keine 8 Bit ausgelesen, noch nicht mal RGB-Daten. Vom Sensor gehen Bayer-Rohdaten mit hier 4K 10 Bit an die CPU, die dann eben das Bayern vornimmt, also den Transfer in das RGB-Format. Das ist rechenintensiv, und dabei wird hier Lineskipping angewendet, aus Gründen wie oben erläutert.

    Heraus kommen dann eben die 2,7k mit 8 Bit Farbtiefe. Berechnest Du die Brutto-Datenmenge, sind das jedoch 2704 x 1520 x 8 Bit pro Bild, x 30 Bilder pro Sekunde = 987 MBit/s (nicht 97 MBit/s.)
    Das wird dann komprimiert (nach einem Transfer der RGB-Bilddaten in den YUV--Raum, dabei wird noch die Farbunterabtastung vorgenommen, hier in 4:2:0).
    Wir reden also bei der Zielbitrate von 40 MBit/s von einem Kompressionsfaktor von grob ca. 25 zu 1.

    Jetzt kommt noch die eigentliche Implementierung des Codes ins Spiel, also mit welchen Parametern der H.264 Codec gefüttert wird. @quadle hat beispielsweise die GOP-Größen erwähnt, also das Verhältnis zwischen vollständig gespeicherten Intraframes und den nur die Änderungen enthaltenen Interframes. Als Beispiel, die Mavic 1 Pro, die sich bezüglich ihrer Codec-Implementation bekanntlich auch nicht gerade mit Ruhm bekleckert, speichet 8 Interframes, dann kommt der nächte Intraframe als neue Referenz. Die Mavic Mini speichert 30 (!) Interframes, dann erst kommt ein neuer Intraframe.
    Gute H.264 Implementationen arbeiten auch mit mehreren Intraframes hintereinander, bspw. 2 - einer ist in die Zukunft, einer in die Vergangenheit als Referenz gerichtet.

    Du siehst also, es ist nicht allein mit Rechnerei an einer isolierten Stelle der Pipeline getan, das Thema ist recht komplex. Und letztlich zählt das Ergebnis, welches man mit kundigem Auge auch gut direkt am Bild analysieren kann, siehe oben.

    Dieser Beitrag wurde bereits 6 mal editiert, zuletzt von skyscope ()

  • Schön, dass Ihr Techniker die technische Diskussion zwischenzeitlich fortgeführt habt ;)

    Ich beurteile letztlich mit meinen noch einigermaßen guten Augen. Das heißt keinesfalls, dass ich technische Daten ausblende; ganz im Gegenteil.
    Wie auch immer welche Technik meine Augen (bei auch Videos) überlistet und ggf. künstlich verbessert, ist mir letztlich egal. Hauptsache, das Überlisten funktioniert :)

    Hier und online haben sich ja schon reichlich Testvideos angesammelt, die ich relativ oft wiederholt gesehen habe.
    Wenn man diesbezüglich Eure 2,7-K-Diskussion verfolgt, wo bei 2,7K die Mini "unvollständig" ausgestattet ist (um es mal so zu nennen), könnte sich vielleicht erklären, warum das 1080p-Material
    deutlich Artefakte-freier wirkt als das 2,7-K-Material. Der gestern hier rein gestellte 2,7K-Clip mit der Aufnahme auf dem Feld hat mich fast geschockt in punkto "Matsch"/Artefakte, obwohl die Lichtbedingungen
    mehr als ausreichend waren. Ggf. wäre das Ergebnis in 1080p besser gewesen.
    Fast geschockt hatte mich auch eines der Testvideos, die @skyscope hier per Link im Original "bereitgestellt hatte"; der Clip mit der kleinen Insel, wo es deutlichste Artefakte im grünen Wasser gab.

  • Heute nochmal etwas einen Garten abgeflogen. Bitte auch hier wieder Nachsicht mit meinen Flugkünsten - ist erst mein zweiter Drohnenflug. ;) Die Fotos finde ich wirklich gut ausgewogen seit dem Firmwareupdate. Bei den Videos ists bei nicht so raschen Bewegungen auch ganz gut. Beim schneller Fliegen wirds leider etwas „matschiger“ - aber überzeugt euch selbst davon:

    drive.google.com/drive/folders…lypNgRPBy2sj_?usp=sharing

    Natürlich alles uneditiert in 2,7K 30 Fps und direkt von der Speicherkarte in den Drive geladen!

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von heda342 ()

  • @heda342

    Herzlichen Glückwunsch! Deine Drohne ist auch mittlerweile da :)
    Hatte mir gleich die Videos eben runtergeladen und 2x jeweils geschaut.
    Ebenfalls Glückwunsch zu den ersten Drohnenflügen. Dachte beim dritten Video "wow, hatte ich mich das gleich damals bei den ersten Flugversuchen getraut"? :)
    Aber großartige Demo! Tolle Stimmung! Da wäre ich auch gerade gerne :) Sieht aus wie im Urlaub.

    Auch hier sieht man, dass die Mini eine sehr hohe Schärfe liefert. Wir haben hier ja von den Experten gelesen, dass hier offenbar visuell getrickst wird. Aber nüchtern nur die Schärfe betrachtet....das haben die bei DJI recht gut hinbekommen. Ob dieses Getrickse zwangsläufig zu Artefakten führen muss....Dafür sehe ich zuwenig Nebeneffekte in den Videos, die ich normal von überschärften Videos her kenne.
    Was man hier sieht ist, dass die Mini beim Fliegen mit den Details kämpft und sie temporär immer wieder verliert. Auch kämpft sie mit Kanten z.B. an den Fenstern oder der Balkonbrüstung.
    In der Szene direkt zwischen Baum und Pflanzen (perfekt gedreht) kommt ja gegen Ende der Schwenk. Den hast du aus meiner Sicht langsam genug gemacht. Das Ergebnis siehst du ja selber.

    Nun 1x Side-Step: Ich habe ja mehrere Kamera-Devices, die alle 4K und 2K können inkl. meiner Air. Ich drehe aus guten eigenen Gründen meist in 1080p, da ich mit diesem Format letztlich am besten "auf Tournee gehen" kann.
    Netflix, Amazon, TV usw. strahlen meist sogar nur 720p aus, je nach Abo und sonstigen Bedingungen. Damit sind wir sicher alle dennoch zufrieden in punkto Videoqualität :)
    Dass meine Air 4K bei 100Mbit/s kann weiß ich. Aus v.g. Gründen aber nicht mein Format.
    Gerade dein letzter Clip: dass hätten meine 3 anderen Kameratypen zum Videofilmen inkl. Schwenk "tadellos" bei 1080p hinbekommen. DJI hat zwar merkwürdiger Weise die Schärfe "manipuliert", aber irgendwie außer acht gelassen, dass Details beim Fliegen und bei Schwenks nicht mitkommen. NEIN...wahrscheinlich nicht außer acht gelassen....bewusst so gewollt.
    Ich hatte gestern übrigens Kontakt mit DJI, wie das so mit nächsten "Upcoming Features" aussieht; womit man rechnen kann. Natürlich "Hey, great ideas"...man würde es direkt an die Entwickler weitergeben. Den Dialog hätte ich mir auch sparen können...aber, man kann's ja mal' versuchen :)

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Bladerunner ()

  • Hier ein aktuelles Mini-Video zum Motivieren/bei der Stange bleiben :)
    So kann ein Mini-Video mit der richtigen Nachbearbeitung aussehen. Ähnliche Videos hatten wir schon öfter in diesem Thread.
    Zum Drohnenfliegen-Hobby gehört halt auch die Nachbearbeitung, die ich genauso seit vielen vielen Jahren spannend finde, wie das Fliegen selber.
    Ich entrausche mit Neat Video so gut wie jeder Footage, da dieses Plugin ganz anders arbeitet als alle anderen Entrauschungsmethoden. Und, es kann auf den Punkt so Nachschärfen, ohne
    ungewollte Nebeneffekte.
    Bei solchen Videos wie dem Folgenden sagen wahrscheinlich nur die Wenigsten "ja, dass wurde ja auch nur mit einer Mini gemacht" :)
    Also ran ans Nachbearbeiten.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Bladerunner ()