If you're putting a video on the web, you can use HTML5's video loop attribute: http://www.w3schools.com/tags/att_video_loop.asp
e.g. http://cordes.ca/Working/clip.html, which loops a short x264-encoded slo-mo clip from the musical Working.
See also Convert video to apng/png?
AFAICT, there are no video container formats (e.g. mp4, mkv, avi, nut, ogm) that ffmpeg supports which have a loop count in the container metadata. So you're right, you'd have to feed the repeating sequence of input frames to a video codec, and hope the encoder can find the massive redundancy.
You can call gif, mng, and webp video formats, since you can store any sequence of frames in them. None of those container formats support anything except the single still-image codec they were designed for, though. They all support animations with looping, probably all with a non-infinite loop count that would give you the 2 minutes you want.
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 can't play back animated webp, so use vwebp, or google chrome.
I have no idea why you would want this. If you have an animated gif, just play it. ffplay -ignore_loop 0 containerloop.gif
will loop for 2 mins (since I made the gif with a finite loop count).
If you're making clips for a video editting project, I guess that makes sense.
[1] x264 with 16 ref frames, max of 8 b frames, fed yuv444 version of the input.
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
Note the average P frame size being smaller than the average B frame.
x264 in lossless mode, rgb or yuv, didn't manage to keep its 16 reference frames lined up in a way that let it keep referencing them without re-encoding them. IDK enough about decoder picture ordering and exactly which frames get kept as references to understand why.