hls_fmp4_init_filename not properly formated

[Dennis Shtatnov]

The documentation for the hls_fmp4_init_filename argument requires that if it is given, that it contains a "%v" string that will be replaced with the variation number. Likewise this is validated by the code here:
​https://github.com/FFmpeg/FFmpeg/blob/c5329d64b1264ef1431732aad6f5b08d0c4b55f4/libavformat/hlsenc.c#L2499

But if a provide a value for it which is not the default ("init.mp4"), the "%v" does not get replaced and instead the variant number seems to have the fixed behavior of always appending it to the filename.

So given a pattern of something_init_%v.mp4, it currently outputs a file named something_init_%v_1.mp4, while I would expect it to output something_init_1.mp4.

If it helps, I think that the appending of the variant to the end occurs here: ​https://github.com/FFmpeg/FFmpeg/blob/c5329d64b1264ef1431732aad6f5b08d0c4b55f4/libavformat/hlsenc.c#L2671, but there does not appear to be any consideration of "%v" in the string.

If I comment out the entire validation block referenced in the first link and use the input pattern something_init.mp4, then it works fine for my needs, but is still inconsistent with the documentation.

How to reproduce:

% ffmpeg ..... -hls_fmp4_init_filename "something_init_%v.mp4" ....

[Marco O.]

I have encountered the same problem and sorted out that it happens only when there is just *one* variant. By giving a look at the code here ​https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/hlsenc.c#L3001 one can see that the %v expansion takes place only

if (hls->nb_varstreams > 1)

User can avoid this by simply not using the %v wildcard if there is just one variant, but this looks to me somewhat as a loss of generality. Fix should be easy, just turn the two ifs into

if (hls->nb_varstreams > 0)