Если вы размещаете видео в Интернете, вы можете использовать атрибут видео цикла HTML5: http://www.w3schools.com/tags/att_video_loop.asp
например, http://cordes.ca/Working/clip.html, который зацикливает короткий кодированный в формате x264 клип slo-mo из музыкального произведения.
Смотрите также Конвертировать видео в apng/png?
AFAICT, нет форматов видео контейнера (например, mp4, mkv, avi, nut, ogm), поддерживаемых ffmpeg, которые имеют количество циклов в метаданных контейнера. Таким образом, вы правы, вам нужно будет передать повторяющуюся последовательность входных кадров в видеокодек и надеяться, что кодировщик найдет огромную избыточность.
Вы можете вызывать gif, mng и webp видео форматы, так как вы можете хранить в них любую последовательность кадров. Ни один из этих форматов контейнеров не поддерживает ничего, кроме одного кодека неподвижного изображения, для которого они были разработаны. Все они поддерживают анимацию с циклом, вероятно, с бесконечным числом циклов, которое даст вам 2 минуты, которые вы хотите.
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 не может воспроизводить анимированные веб-страницы, поэтому используйте vwebp или google chrome.
Я понятия не имею, почему ты этого хочешь. Если у вас есть анимированный GIF, просто играйте в него. ffplay -ignore_loop 0 containerloop.gif будет зацикливаться в течение 2 минут (так как я сделал gif с конечным числом циклов).
Если вы делаете клипы для проекта редактирования видео, я думаю, это имеет смысл.
[1] x264 с 16 ссылочными кадрами, максимум 8 б кадрами, фид yuv444 версия входа.
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
Обратите внимание, что средний размер P-кадра меньше среднего B-кадра.
x264 в режиме без потерь, rgb или yuv, не сумели выстроить свои 16 опорных кадров таким образом, чтобы позволить им продолжать ссылаться на них, не перекодируя их. ИДК достаточно о порядке изображения декодера и о том, какие именно кадры хранятся в качестве ссылок, чтобы понять, почему.
