Nesta página, descrevemos uma especificação que permite que arquivos MP4 incorporem metadados sobre o movimento da câmera durante a captura de vídeo. Os dispositivos que capturam vídeos geralmente têm 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 dos sensores pode ser usada para rastrear os três graus de liberdade (3DoF) dos dispositivos.
- A localização e o mapeamento simultâneos (SLAM, na sigla em inglês) podem ser usados para rastrear a posição de 6 graus de liberdade (6DoF) do dispositivo (por exemplo, Tango).
- As informações de exposição podem ser usadas para interpolar o movimento por digitalização.
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 frame podem ser usadas para estabilizar vídeos, e os dados de movimento no nível da digitalização podem ser usados para reduzir os efeitos de rolagem do obturador.
- As leituras de IMU e as posições derivadas de 3DoF podem ser usadas para avaliar o alinhamento do tempo e o alinhamento geométrico entre a IMU e a câmera.
As seções abaixo especificam a faixa CAmera Motion Metadata (CAMM), que inclui uma nova entrada de amostra que indica a existência da faixa e o formato dos dados delas.
Exemplo de entrada
O arquivo de vídeo precisa conter a seguinte caixa de entrada de amostra para indicar a faixa de metadados
personalizada, e o subComponentType da faixa 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 stream de amostras de metadados no formato a seguir.
| Campo | Unidade | Descrição |
|---|---|---|
uint16 reserved; |
Reservado. Precisa ser 0. | |
uint16 type; |
O tipo do pacote de dados (veja abaixo). Cada pacote tem um tipo de dado. | |
switch (type) { |
||
case 0:
float angle_axis[3];
break;
|
Orientação do eixo angular em radianos que representam a rotação de coordenadas da câmera local para um sistema de coordenadas mundial. O sistema de coordenadas mundial é definido pelos aplicativos. Permita que M seja a matriz de rotação 3 x 3 correspondente ao vetor de eixo angular. Para qualquer raio x no sistema de coordenadas local, a direção do raio na coordenada mundial é M * X. Para conseguir essas informações, execute a fusão do sensor 3DoF no dispositivo. Depois da integração das leituras de IMU, apenas 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 fornecido pelo comprimento do vetor e o eixo de rotação seja fornecido pelo vetor normalizado. A representação codificada pode ser criada a partir de um eixo e ângulo com Além disso, a representação codificada pode ser transformada em um eixo e ângulo com |
|
case 1:
int32 pixel_exposure_time;
int32 rolling_shutter_skew_time;
break;
|
nanossegundos |
Esses metadados são por frame de vídeo. O tempo de apresentação (PTS, na sigla em inglês) desses metadados precisa ser o início da exposição da primeira linha de verificaçã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 a exposição da primeira linha usada e da última linha usada. Elas podem ser usadas para interpolar metadados por verificação. O PTS do frame correspondente precisa estar entre pts_of_this_metadata e pts_of_this_metadata + pixel_exposure_time_ns + roll_shutter_skew_time_ns. Quando essas informações não são salvas, o dispositivo faz o possível para ajustar o PTS do frame do vídeo de modo 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 em torno dos eixos XYZ da câmera. A rotação é positiva no sentido anti-horário. Os aplicativos definem a relação entre o sistema de coordenadas IMU e o sistema de coordenadas da câmera. Recomendamos alinhá-las se possível. As leituras iniciais do giroscópio estão no sistema de coordenadas IMU definido pelo motorista. A transformação adequada é necessária para convertê-las em sistemas 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 IMU e o sistema de coordenadas da câmera. Recomendamos alinhá-las se possível. Consulte o sensor Sensor.TYPE_ACCELEROMETER do Android. |
case 4:
float position[3];
break;
|
Posição 3D da câmera. A rotação de eixo angular e posição 3D define a posição da câmera 6DoF da câmera, e eles estão em um sistema de coordenadas comum definido pelo aplicativo. Para ver essas informações, execute o monitoramento de 6DoF no dispositivo. |
|
case 5:
double latitude;
double longitude;
double altitude;
break;
|
graus |
Coordenada mínima do GPS 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_ armazenamento: tempo desde a época do GPS em que a medição foi realizada 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 WGS-84 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 da 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 contém todos os tipos de dados acima ao misturar os dois.
- As amostras de GPS nos casos 5 e 6 precisam ser valores brutos gerados por sensores. Eles não podem ser interpolados ou repetidos quando não há mudanças no GPS.
- Os sistemas de coordenadas têm as laterais direitas. O sistema de coordenadas da câmera é definido como X apontando para a direita, Y para baixo e Z para frente. O eixo Y do sistema de coordenadas global precisa apontar para baixo ao vetor de gravidade.
- As leituras de IMU geralmente estão em um sistema de coordenadas IMU separado, e a rotação é necessária para mapeá-los para o sistema de coordenadas da câmera se os dois sistemas de coordenadas forem diferentes.
- Todos os campos são do tipo end-end (o byte menos significativo primeiro), e os pontos flutuantes de 32 bits têm o formato IEEE 754-1985.
- Para sincronizar com precisão o frame do vídeo e os metadados, o PTS dele precisa estar no centro da exposição. Isso também pode ser inferido usando metadados de exposição.
- O aplicativo que faz a multiplexação desses dados precisa escolher uma escala de tempo grande o suficiente para ter um PTS preciso.
Possíveis problemas
-
Este design permite apenas um pacote por amostra de dados. Os dispositivos incorporados podem ter problemas para escrever
pacotes de frequência muito altos porque aumentam a pressão de E/S, bem como o tamanho do cabeçalho
(por exemplo, os átomos
stscestsz) se o tamanho do pacote varia. - Misturar diferentes tipos de dados com diferentes atrasos pode fazer o PTS avançar e voltar à medida que os pacotes são gravados no arquivo. No entanto, isso pode ser resolvido armazenando pacotes em buffer e gravando em ordem monotônica.