Se você estiver colocando um vídeo na Web, poderá usar o atributo de loop de vídeo do HTML5: link
por exemplo. link , que faz um pequeno clipe slo-mo codificado em x264 do musical Working.
Veja também Converter vídeo para apng / png?
AFAICT, não há formatos de contêiner de vídeo (por exemplo, mp4, mkv, avi, nut, ogm) que o ffmpeg suporte e que tenham uma contagem de loop nos metadados do contêiner. Então você está certo, você teria que alimentar a seqüência de repetição de quadros de entrada para um codec de vídeo, e espero que o codificador possa encontrar a redundância maciça.
Você pode chamar os formatos de vídeo gif, mng e webp, já que você pode armazenar qualquer sequência de quadros neles. Nenhum desses formatos de contêiner suporta qualquer coisa, exceto o único codec de imagem estática para o qual foram projetados. Todos eles suportam animações com looping, provavelmente todos com uma contagem de loop não infinita que lhe daria os 2 minutos que você deseja.
ffmpeg -framerate 15 -loop 1 -i src/b93-'%d.png' -frames 1805 -preset veryslow -crf 23 -movflags +faststart party.mp4
2.5M party.mp4 # see [1] for the encode log
ffmpeg -framerate 15 -i src/b93-'%d.png' -loop 128 containerloop.gif
684K containerloop.gif
...
172K containerloop.webp
ffplay não pode reproduzir webp animado, portanto use o vwebp ou o google chrome.
Eu não tenho ideia de por que você iria querer isso. Se você tiver um gif animado, apenas o toque. ffplay -ignore_loop 0 containerloop.gif
fará um loop por 2 minutos (desde que fiz o gif com uma contagem de loop finita).
Se você está criando clipes para um projeto de edição de vídeo, acho que isso faz sentido.
[1] x264 com 16 quadros ref, máximo de 8 quadros b, alimentados com a versão yuv444 da entrada.
frame= 1805 fps=7.2 q=-1.0 Lsize= 2540kB time=00:02:00.20 bitrate= 173.1kbits/s
video:2518kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.872666%
[libx264 @ 0x1a787e0] frame I:8 Avg QP:21.35 size: 18650
[libx264 @ 0x1a787e0] frame P:515 Avg QP:16.45 size: 1044
[libx264 @ 0x1a787e0] frame B:1282 Avg QP:25.79 size: 1475
[libx264 @ 0x1a787e0] consecutive B-frames: 0.7% 13.9% 0.8% 84.2% 0.0% 0.0% 0.0% 0.4% 0.0%
[libx264 @ 0x1a787e0] mb I I16..4: 3.4% 64.4% 32.2%
[libx264 @ 0x1a787e0] mb P I16..4: 0.9% 15.9% 0.9% P16..4: 80.9% 0.3% 0.6% 0.0% 0.0% skip: 0.5%
[libx264 @ 0x1a787e0] mb B I16..4: 0.3% 2.8% 0.5% B16..8: 4.8% 3.3% 1.9% direct: 1.2% skip:85.2% L0:35.1% L1:64.0% BI: 0.9%
[libx264 @ 0x1a787e0] Weighted P-Frames: Y:75.0% UV:75.0%
[libx264 @ 0x1a787e0] ref P L0: 1.3% 0.1% 0.7% 0.1% 0.3% 0.0% 24.1% 41.7% 27.4% 0.1% 0.0% 0.0% 0.0% 0.4% 3.5% 0.4%
[libx264 @ 0x1a787e0] ref B L0: 8.7% 1.6% 0.8% 0.1% 0.7% 1.2% 74.6% 2.1% 0.0% 0.1% 0.0% 0.0% 0.4% 9.5%
[libx264 @ 0x1a787e0] ref B L1: 99.5% 0.5%
[libx264 @ 0x1a787e0] kb/s:171.40
Observe que o tamanho médio do quadro P é menor que o quadro médio B.
O
x264 no modo sem perdas, rgb ou yuv, não conseguiu manter seus 16 quadros de referência alinhados de forma a permitir que eles continuem referenciando-os sem recodificá-los. IDK suficiente sobre a ordenação de imagens do decodificador e exatamente quais quadros são mantidos como referências para entender o motivo.