Esta página descreve uma especificação que permite que arquivos MP4 sejam incorporados metadados sobre o movimento da câmera durante a captura de vídeo. Os dispositivos que capturam vídeo geralmente têm ou sensores que podem fornecer informações adicionais sobre a captura. Exemplo:
- Os smartphones geralmente têm sensores de giroscópio, acelerômetro, magnetômetro e GPS.
- A "fusão do sensor" pode ser usada para monitorar a posição dos 3 graus de liberdade (3DoF, na sigla em inglês) dos dispositivos.
- A localização e o mapeamento simultâneos (SLAM) podem ser usados para acompanhar os seis graus de liberdade (6DoF) do dispositivo (por exemplo, Tango).
- As informações de exposição podem ser usadas para interpolar o movimento por varredura.
Esses metadados podem ser salvos no vídeo para pós-processamento avançado em vários aplicativos. Exemplo:
- As informações de rotação no nível do quadro podem ser usadas para estabilizar os vídeos, e os dados de movimento no nível da linha de varredura podem ser usados para reduzir os efeitos do obturador em movimento.
- As leituras da IMU e as posições derivadas de 3DoF podem ser usadas para avaliar o alinhamento de tempo e geométrico entre a IMU e a câmera.
As seções abaixo especificam a faixa da CAmera Motion Metadata (CAMM), que inclui uma nova amostra entrada que indica a existência da faixa e o formato de dados de amostras de faixas.
Entrada de amostra
O arquivo de vídeo deve conter o exemplo de caixa de entrada a seguir para indicar os metadados personalizados
e o subComponentType
dela precisa ser definido como meta
.
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') { }
Formato de dados
A faixa de metadados contém um fluxo de amostras de metadados formatadas da seguinte maneira.
Campo | Unidade | Descrição |
---|---|---|
uint16 reserved; |
Reservado. Deve ser 0. | |
uint16 type; |
O tipo do pacote de dados (veja abaixo). Cada pacote tem um tipo de dados. | |
switch (type) { |
||
case 0: float angle_axis[3]; break; |
Orientação do eixo do ângulo em radianos que representam a rotação das coordenadas locais da câmera para um sistema de coordenadas mundiais. O sistema de coordenadas mundiais é definido por aplicativos. Permita que M seja a matriz de rotação 3x3 correspondente ao vetor do eixo do ângulo. Para qualquer raio X no sistema de coordenadas local, a direção do raio na coordenada mundial é M * X. Essas informações podem ser obtidas executando a fusão do sensor 3DoF no dispositivo. Depois de integrar as leituras da IMU, somente a orientação global integrada precisa ser gravada. Os três valores representam o vetor do eixo angular, de modo que o ângulo de rotação em radianos seja determinado pelo comprimento do vetor e o eixo de rotação seja fornecido pelo vetor normalizado. A representação codificada pode ser criada usando um eixo e ângulo com E a representação codificada pode ser transformada de volta em um eixo e ângulo com |
|
case 1: int32 pixel_exposure_time; int32 rolling_shutter_skew_time; break; |
nanossegundos |
Os metadados são por frame de vídeo. O tempo de apresentação (PTS) desses metadados deve ser o início da exposição da primeira linha de digitalização usada em um frame de vídeo. pixel_exposure_time_ns é o tempo de exposição de um único pixel em nanossegundos e rolling_shutter_skew_time_ns é o atraso entre o exposição da primeira linha usada e da última linha usada. Eles podem ser usados para interpolar metadados por verificação. O PTS do frame correspondente precisa estar dentro de pts_of_this_metadata e pts_of_this_metadata + pixel_exposure_time_ns + rolling_shutter_skew_time_ns. Quando essas informações não são salvas, o dispositivo tenta ao máximo ajustar o PTS do frame do vídeo para que ele fique no centro da exposição do frame. |
case 2: float gyro[3]; break; |
radianos/segundos |
Sinal do giroscópio em radianos/segundos ao redor dos eixos XYZ da câmera. A rotação é positivo no sentido anti-horário. Os aplicativos definem a relação entre o sistema de coordenadas da IMU e a câmera sistema de coordenadas. Recomendamos alinhá-los, se possível. As leituras iniciais do giroscópio estão no sistema de coordenadas da IMU definido pelo driver, e uma transformação adequada é necessária para convertê-lo no sistema de coordenadas da câmera. Consulte Android Sensor.TYPE_GYROSCOPE. |
case 3: float acceleration[3]; break; |
metros/segundos^2 |
Leitura do acelerômetro em metros/segundo^2 ao longo dos eixos XYZ da câmera. Os aplicativos definem a relação entre o sistema de coordenadas da IMU e a câmera sistema de coordenadas. Recomendamos alinhá-los, se possível. Consulte Android Sensor.TYPE_ACCELEROMETER. |
case 4: float position[3]; break; |
Posição 3D da câmera. A posição 3D e a rotação do eixo angular definem Posição de 6DoF da câmera e estão em uma coordenada comum definida pelo aplicativo sistema. Você pode obter essas informações executando o monitoramento 6DoF no dispositivo. |
|
case 5: double latitude; double longitude; double altitude; break; |
graus |
Coordenada de GPS mínima da amostra. |
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: é o tempo desde a época do GPS em que a medição foi feita. gps_fix_type: 0 ( sem correção), 2 (correção 2D), 3 (correção 3D) latitude: latitude em graus longitude: longitude em graus altitude: altura acima do elipsoide WGS84 horizontal_accuracy: precisão horizontal (lat/long) vertical_accuracy: precisão vertical (altitude) velocity_east: velocidade na direção leste velocity_north: velocidade na direção norte velocity_up: velocidade na direção para cima speed_accuracy: precisão de velocidade |
case 7: float magnetic_field[3]; break; |
microtesla |
Campo magnético do ambiente. Consulte Android Sensor.TYPE_MAGNETIC_FIELD. |
} |
Observações
- Deve haver apenas uma faixa CAMM por arquivo MP4, que contenha todos os tipos de dados acima ao mesclá-los.
- As amostras de GPS nos casos 5 e 6 precisam ser valores brutos gerados pelos sensores. Não podem ser interpolado ou repetido quando não há mudança no GPS.
- Os sistemas de coordenadas ficam do lado direito. O sistema de coordenadas da câmera é definido como X apontando para a direita, Y apontando para baixo e Z apontando para frente. O eixo Y da escala global de coordenadas deve apontar para baixo ao longo do vetor de gravidade.
- As leituras de IMU normalmente ficam em um sistema de coordenadas de IMU separado, e a rotação é necessária para mapeá-las para o sistema de coordenadas da câmera se os dois sistemas forem diferentes.
- Todos os campos são small-endian (byte menos significativo primeiro) e os campos flutuantes de 32 bits estão no formato IEEE 754-1985.
- Para sincronizar com precisão o frame do vídeo e os metadados, o PTS do frame do vídeo precisa estar no centro da exposição, o que também pode ser inferido a partir de metadados de exposição.
- O aplicativo que mixa esses dados deve escolher uma escala de tempo grande o suficiente para obter uma PTS mais preciso.
Possíveis problemas
-
Esse projeto permite apenas um pacote por amostra de dados. Dispositivos incorporados podem ter problemas de gravação
de pacotes com frequência muito alta, porque aumenta a pressão de E/S, bem como o tamanho do cabeçalho
(por exemplo, os átomos
stsc
estsz
) se o tamanho do pacote variar. - Misturar diferentes tipos de dados com diferentes atrasos pode fazer com que o PTS vá adiante e para trás à medida que os pacotes são gravados no arquivo. No entanto, isso pode ser superado armazenar pacotes em buffer e gravá-los em ordem monotônica.