Minha exigência é enquadrar com precisão (alguns quadros para cima / baixo) cortar o fluxo de vídeo https mp4 (h264 + aac) com ffmpeg no celular mais rápido possível - o que significa que eu trocaria se necessário compactação ruim (maior saída arquivo) para maior velocidade de corte. Atualmente estou cortando o vídeo com este comando:
ffmpeg -ss [start_time] -i https://domain/in.mp4 -t 00:00:10.000 -c:a copy -c:v copy out.mp4
Essa abordagem (cópia de fluxo de bits) é muito rápida (menos de um segundo em uma boa rede por um longo corte de vídeo de 10 segundos), mas não está cortando o vídeo com precisão. O vídeo está sendo cortado em quadros-chave, o que é impreciso.
Então, minha ideia é compensar essa imprecisão (distância do quadro-chave) buscando em vídeo antes de reproduzi-lo para:
delta = start_time - first_key_frame_timestamp_before_start_time
Para calcular delta, preciso de uma maneira muito rápida de obter time_stamp do primeiro quadro-chave antes do horário de início. Eu vi post que explica como obter o timestamp do primeiro key-frame antes de start_time, mas essa abordagem não é prática para vídeos longos (2 horas +) porque levaria muito tempo para que essa operação alcance o meio do vídeo. Eu precisaria de algo assim:
ffmpeg -ss 01:30:06.000 -i https://domain/in.mp4 -t 2 -show_frames > frame_meta.txt
Eu também tentei fazer cortes precisos ao recodificar o vídeo (2 horas de vídeo longo, 10 segundos de corte de vídeo no meio do vídeo) com este comando:
ffmpeg -ss [start_time] -i https://domain/in.mp4 -t 10 out.mp4
mas leva muito tempo (~ 16 segundos) no celular para terminar em comparação com menos de um segundo comando de cópia de fluxo de bits. Thx para qualquer dica ou solução útil.
EDIT 1:
Eu consegui calcular o delta e obter o timestamp do primeiro keyFrame antes de start_time usando as classes internas do ExoPlayer (player multimídia Android) e essa abordagem é muito rápida: 500ms (vídeos muito curtos) até 1500ms (para vídeos muito longos). Essencialmente, essa abordagem é baseada na análise de meta_headers (moov atom) do fluxo mp4 remoto para encontrar o timeStamp adequado de keyFrame antes de cortar start_time. Agora NEW PROBLEM surge quando o vídeo é cortado com:
ffmpeg -ss [start_time] -i https://domain/in.mp4 -t 00:00:10.000 -c:a copy -c:v copy out.mp4
O atom da lista de edição é adicionado ao cabeçalho meta, conforme entendido de este e esta postagem que está lá para dizer ao jogador para começar a jogar com delta de tempo delta para compensar o corte de vídeo impreciso que é feito com o comando ffmpeg bitStream copy . Mas os players que eu uso no Android não suportam playbacks de listas de edição porque eles apenas começam a tocar normalmente desde o início do vídeo ou são congelados em alguns quadros por alguns momentos enquanto o áudio está sendo reproduzido e então continuam tocando normalmente.
Quando tento procurar delta previamente calculado e, em seguida, inicio a reprodução em vídeo cortado, não sou posicionado no quadro correto (por exemplo, delta calculado = 1 381ms mas delta real / trabalho = 444ms) e meu plano para compensar o corte impreciso é não está funcionando :(. Se você está se perguntando se eu calculei corretamente delta eu verifiquei com IsoViewer (analisador de átomo de contêiner mp4 ) e mannualy percorrendo frames com o Avidemux e procurando no par de valores time_stamp / frame_type ...