Diese Seite wurde von der Cloud Translation API übersetzt.

Spezifikation der Kamerabewegungsmetadaten

Auf dieser Seite wird eine Spezifikation beschrieben, mit der MP4-Dateien bei der Videoaufnahme Metadaten zu Kamerabewegungen einbetten können. Geräte, die Videos aufnehmen, haben in der Regel Sensoren, die zusätzliche Informationen zur Aufnahme liefern können. Beispiel:

Smartphones haben normalerweise Sensoren für Gyroskop, Beschleunigungsmesser, Magnetometer und GPS.
Mit der Sensor-Zusammenführung lässt sich die 3D-Freiheit (3DoF) von Geräten erfassen.
Mit der simultanen Lokalisierung und Kartierung (SLAM) können die 6 Freiheitspositionen (6DoF) des Geräts (z. B. Tango) verfolgt werden.
Informationen zur Begegnung mit einer infizierten Person können verwendet werden, um Bewegungen pro Scan zu interpolieren.

Diese Metadaten können im Video zur erweiterten Nachbearbeitung in verschiedenen Anwendungen gespeichert werden. Beispiel:

Mit den Informationen auf Rotationsebene auf Frame-Ebene können Videos stabilisiert werden. Mit Bewegungsdaten auf Scanebene können verringerte Auslöser eingeschränkt werden.
Mit IMU-Messungen und abgeleiteten 3DoF-Positionen können die zeitliche und die geometrische Ausrichtung zwischen IMU und Kamera ausgewertet werden.

In den folgenden Abschnitten wird der CAmera Motion-Metadaten-Track (CAMM) angegeben. Er enthält einen neuen Beispieleintrag, der das Vorhandensein des Tracks und das Datenformat der Track-Stichproben angibt.

Beispieleintrag

Die Videodatei sollte das folgende Beispieleingabefeld enthalten, um den benutzerdefinierten Metadaten-Track anzugeben. Außerdem sollte der subComponentType des Tracks auf meta gesetzt sein.

Camera Motion Metadata Sample Entry (camm)

Definition
Box Type: camm
Container: stsd
A sample entry indicating the data track that saves the camera motion.

Syntax
aligned(8) class CameraMotionMetadataSampleEntry extends SampleEntry('camm') {
}

Datenformat

Der Metadaten-Track enthält einen Stream von Metadatenbeispielen, die so formatiert sind:

Feld	Einheit	Beschreibung
uint16 reserved;		Reserviert. Sollte 0 sein.
uint16 type;		Der Typ des Datenpakets (siehe unten). Jedes Paket hat einen Datentyp.
switch (type) {
case 0: float angle_axis[3]; break;		Winkelachsenausrichtung im Bogenmaß, das die Rotation von lokalen Kamerakoordinaten zu einem Weltkoordinatensystem darstellt Das Weltkoordinatensystem wird durch Anwendungen definiert. M ist die 3 x 3-Rotationsmatrix, die dem Achsenvektor der Winkel entspricht. Für jeden Ray X im lokalen Koordinatensystem ist die Strahlrichtung in der Weltkoordinate M * X. Diese Informationen erhalten Sie, indem Sie die 3DoF-Sensorzusammenführung auf dem Gerät ausführen. Nach der Integration der IMU-Werte muss nur die integrierte globale Ausrichtung aufgezeichnet werden. Die drei Werte stehen für den Winkelachsenvektor, sodass der Rotationswinkel im Bogenmaß durch die Länge des Vektors und die Rotationsachse durch den normalisierten Vektor angegeben wird. Die codierte Darstellung kann mit einer Achse und einem Winkel mit `float[3] angle_axis := angle_radians * normalized_axis_vec3` erstellt werden. Ein positiver Winkel stellt die Drehung gegen die Achse gegen den Uhrzeigersinn dar. Die codierte Darstellung lässt sich mit `float[3] axis := normalize(axis_angle)` und `float angle_radians := length(angle_axis)` wieder in eine Achse und einen Winkel umwandeln.
case 1: int32 pixel_exposure_time; int32 rolling_shutter_skew_time; break;	Nanosekunden	Diese Metadaten gelten pro Videoframe. Die Präsentationszeit (PTS) dieser Metadaten sollte der Beginn der Sichtbarkeit der ersten verwendeten Scanline in einem Videoframe sein. pixel_exposure_time_ns ist die Belichtungszeit für ein einzelnes Pixel in Nanosekunden und rolling_shutter_skew_time_ns ist die Verzögerung zwischen der Belichtung des ersten und des letzten Scans. Sie können für interpolierende Metadaten pro Scan verwendet werden. Der PTS des entsprechenden Frames sollte sich innerhalb von pts_of_this_metadata und pts_of_this_metadata + pixel_exposure_time_ns + gleitende_shutter_skew_time_ns befinden. Wenn diese Informationen nicht gespeichert werden, versucht das Gerät, die PTS des Videoframes so zu verändern, dass die Bildmitte im Mittelpunkt ist.
case 2: float gyro[3]; break;	Bogenmaß/Sekunde	Gyroskopsignal in Radiant/Sekunde um XYZ-Achsen der Kamera. Rotation ist entgegen dem Uhrzeigersinn positiv. Anwendungen definieren die Beziehung zwischen dem IMU-Koordinatensystem und dem Kamerakoordinatensystem. Wir empfehlen, sie nach Möglichkeit auszurichten. Die ersten Gyrosanzeigewerte befinden sich im IMU-Koordinatensystem, das vom Fahrer definiert wird. Daher ist eine ordnungsgemäße Umwandlung erforderlich, um sie in das Kamerakoordinatensystem umzuwandeln. Weitere Informationen findest du unter Android Sensor.TYPE_GYROSCOPE.
case 3: float acceleration[3]; break;	Meter/Sekunden^2	Beschleunigungsmesser in Metern/Sekunde^2 entlang der XYZ-Achse der Kamera. Anwendungen definieren die Beziehung zwischen dem IMU-Koordinatensystem und dem Kamerakoordinatensystem. Wir empfehlen, sie nach Möglichkeit auszurichten. Weitere Informationen findest du unter Android Sensor.TYPE_ACCELEROMETER.
case 4: float position[3]; break;		3D-Position der Kamera. Die 3D-Positionierung und die Rotation auf der Achse 3D definieren die 6DoF-Position der Kamera und befinden sich in einem gemeinsamen anwendungsdefinierten Koordinatensystem. Sie erhalten diese Informationen, wenn Sie 6DoF-Tracking auf dem Gerät ausführen.
case 5: double latitude; double longitude; double altitude; break;	Grad	Minimale GPS-Koordinate der Stichprobe. Hinweis: Die GPS-Beispiele müssen Rohwerte sein und dürfen nicht interpoliert oder wiederholt werden, wenn sich keine Änderung ergibt.
case 6: double time_gps_epoch; int gps_fix_type; double latitude; double longitude; float altitude; float horizontal_accuracy; float vertical_accuracy; float velocity_east; float velocity_north; float velocity_up; float speed_accuracy; break;	seconds degrees degrees meters meters meters meters/seconds meters/seconds meters/seconds meters/seconds	time_gps_epoch – Zeit seit der GPS-Epoche, zu der die Messung ausgeführt wurde gps_fix_type – 0 ( keine Korrektur), 2 (2D-Korrektur), 3 (3D-Korrektur) latitude – Breitengrad in Grad longitude – Längengrad in Grad height – Höhe über dem Ellipsoid WGS-84 horizontal_accuracy – Horizontale (lat./long) Genauigkeit vertical_accuracy – Vertikale (Höhe) Genauigkeit velocity_east – Geschwindigkeit in östlicher Richtung velocity_north – Geschwindigkeit in nördlicher Richtung velocity_up – Geschwindigkeit nach oben speed_accuracy – Geschwindigkeitsgenauigkeit Hinweis: Die GPS-Beispiele müssen Rohwerte sein und dürfen nicht interpoliert oder wiederholt werden, wenn sich keine Änderung ergibt.
case 7: float magnetic_field[3]; break;	Mikrotesla	Magnetfeld für die Umgebung. Weitere Informationen finden Sie unter Android Sensor.TYPE_MAGNETIC_FIELD.
}

Hinweise

Pro MP4-Datei sollte nur ein CAMM-Track vorhanden sein, der alle oben genannten Datentypen enthält, indem sie zusammengefügt werden.
Die GPS-Beispiele in den Fällen 5 und 6 müssen aus von Sensoren generierten Rohwerten stammen. Sie können nicht interpoliert oder wiederholt werden, wenn kein GPS-Wechsel erfolgt.
Die Koordinatensysteme befinden sich auf der rechten Seite. Das Kamerakoordinatensystem ist definiert als X nach rechts, Y nach unten und Z nach vorn. Die Y-Achse des globalen Koordinatensystems sollte auf dem Schwerkraftvektor nach unten zeigen.
Die IMU-Werte befinden sich normalerweise in einem separaten IMU-Koordinatensystem. Wenn die beiden Koordinatensysteme sich unterscheiden, ist eine Rotation erforderlich, um sie dem Kamerakoordinatensystem zuzuordnen.
Alle Felder sind Little-Endians (am wenigsten signifikantes Byte zuerst) und die 32-Bit-Gleitkommazahlen haben das Format IEEE 754-1985.
Damit der Videoframe und die Metadaten genau synchronisiert werden können, sollte der PTS-Wert des Videoframes in der Mitte der Belichtung liegen (kann auch aus den Metadaten der Kontakte abgeleitet werden).
Die Anwendung, die diese Daten muxiert, sollte eine ausreichend lange Zeitskala auswählen, um einen genauen PTS-Wert zu erhalten.

Mögliche Probleme

Bei diesem Design ist nur ein Paket pro Datenstichprobe zulässig. Eingebettete Geräte können Probleme beim Schreiben von Hochfrequenzpaketen haben, da sich dadurch der E/A-Druck und die Größe des Headers (z. B. die Atome stsc und stsz) erhöht, wenn die Paketgröße variiert.
Wenn verschiedene Datentypen mit unterschiedlichen Verzögerungen vermischt werden, kann der PTS sowohl vorwärts als auch rückwärts geleitet werden, wenn Pakete in die Datei geschrieben werden. Dies kann jedoch durch Zwischenspeichern von Paketen in monotoner Reihenfolge überwunden werden.