Início / computer / Perguntas / 1826227
Accepted
Binarus
Asked: 2024-01-18 04:53:53 +0800 CST

ffmpeg eliminando frames ou gravando carimbos de data / hora PTS inválidos: Bug ou erro meu?

  • 772

Percebi que o ffmpeg às vezes grava carimbos de data/hora PTS inválidos ao usar -tuma entrada M2TS. Este é um erro meu ou é um bug no ffmpeg?

Passos para reproduzir:

Baixe este arquivo M2TS e salve-o como 1.m2ts. Este arquivo contém um stream de vídeo com 25 fps(ou seja, um quadro de vídeo ocupa exatamente 0.04 s( 40 ms)) e um stream de áudio que não é interessante para o propósito deste post.

Abra o terminal, navegue até o diretório que contém o arquivo e execute o seguinte comando:

ffmpeg.exe -i 1.m2ts -codec copy -map 0 -t 2 2.m2ts

Agora examine o arquivo de saída, 2.m2tse observe que o PTS do quadro de vídeo mais recente é 3.560, e que o PTS do quadro de vídeo anterior é 3.480.

Isto obviamente está errado. Após o quadro em 3.480, o próximo quadro deve ser apresentado em 3.520, não 3.560. O ffmpeg descartou o quadro de vídeo que deveria aparecer 3.520ou gravou um PTS errado no último quadro de vídeo ( 3.560em vez de 3.520).

Claro, quando falo de “último” ou “antes”, estou me referindo à ordem dos frames no tempo (mais precisamente, ordenei os frames do vídeo por PTS), não à ordem dos frames no arquivo.

Pergunta:

Isso é um bug no ffmpeg ou há um erro no meu comando acima?

versão do ffmpeg:

ffmpeg version 2024-01-14-git-34a47b97de-full_build-www.gyan.devno Windows 10 x64 Empresarial

Observações adicionais:

Percebi o problema com vários dos meus arquivos M2TS; Não tenho tempo para testar outros formatos. Infelizmente, não posso fornecer meus arquivos para download. Essa é a razão pela qual vinculei a outro arquivo.

Em outras palavras: O problema não é específico do arquivo que vinculei. Em vez disso, encontrei-o com várias taxas de quadros de vídeo e trilhas de áudio em vários arquivos M2TS de diferentes fontes.

Ainda não investiguei as faixas de áudio em relação a lacunas semelhantes.

ffmpeg

1 respostas

  1. Best Answer

    Isso não é um bug, apenas resultado da dependência de quadros B.

    O stream de vídeo possui 3 tipos de frames:

    • I-Frame - não depende de nenhum quadro.
    • P-Frame - dependente apenas dos frames anteriores.
    • Quadro B - depende dos quadros anteriores e posteriores ao quadro codificado.

    O último quadro de vídeo codificado que corresponde a 2 segundos de duração é um B-Frame .
    O primeiro quadro em 2.m2ts possui pts_time=1.48.
    O último quadro em 2.m2ts deveria ter pts_time=3.48.

    Como o quadro pts_time=3.48é um quadro B, ele depende do quadro P que foi codificado depois dele.
    O P-Frame que vem depois tem pts_time=3.56.
    Sem esse P-Frame, é impossível decodificar o B-Frame, então o muxer mantém o último P-Frame extra.

    Analisando os frames do vídeo usando FFprobe:

    Podemos usar FFprobe para obter pts_time e pict_type dos streams de vídeo dos 2 arquivos.

    ffprobe -select_streams v -of default=noprint_wrappers=1:nokey=1 -show_entries frame=pts_time,pict_type 1.m2ts > 1.txt

    ffprobe -select_streams v -of default=noprint_wrappers=1:nokey=1 -show_entries frame=pts_time,pict_type 2.m2ts > 2.txt

    Comparar os arquivos usando a ferramenta de comparação fornece o seguinte resultado:

    1.txt       2.txt
------      ------

1.480000    1.480000
I           I
...
B           B
3.040000    3.040000
B           B
3.080000    3.080000
P           P
3.120000    3.120000
B           B
3.160000    3.160000
B           B
3.200000    3.200000
B           B
3.240000    3.240000
P           P
3.280000    3.280000
B           B
3.320000    3.320000
B           B
3.360000    3.360000
B           B
3.400000    3.400000
P           P
3.440000    3.440000
B           B
3.480000    3.480000
B           B
3.520000    
B           
3.560000    3.560000
P           P

    Observe que o B-Frame pts_time=3.52não é necessário para decodificação 3.48( 3.48depende do 3.56P-Frame, mas não desse 3.52B-Frame), portanto 3.52é ignorado.

    • 2

relate perguntas