filename limited to 1024

[David Charbonnier]

It could make sense to limit the filename to 1024 but this variable is also used by the tee muxer and contain all the options, when using the dash and hls format it's easy to go over those 1024 characters.
If you go over the 1024 character you got inconsistent error messages about your options. Hard to spot that the issue is that the string is truncated, this value should be at least doubled and an error message should be displayed explaining that this option is limited to a number of characters.

see avformat.h and tee_common.c using the filename to parse the options

   /**
     * input or output filename
     *
     * - demuxing: set by avformat_open_input()
     * - muxing: may be set by the caller before avformat_write_header()
     */
    char filename[1024];

[Carl Eugen Hoyos]

Please either send a patch - made with git format-patch - to the development mailing list or provide a command line together with its complete, uncut console output that allows to reproduce the issue.

[David Charbonnier]

Simple example, keep in mind that the limit if not for the hls_segment_filename parameter but for the total size of the options.

ffmpeg -i video.mp4 -c copy -f tee -map 0:v -map 0:a "[hls_segment_filename=`printf 'a%.0s' {1..1024}`]file.m3u8"

[tee @ 0x55effd97bd20] No option found near ""
[tee @ 0x55effd97bd20] All tee outputs failed.
Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument

Subscribing to a mailing list, creating a patch entering a debate in the size of the filename or better design is too complicated to change 1024 to 2048 (dreaming about github or gitlab...). It solved my specific problem and may introduce other ones that I personally don't hit with my patch. My contribution is to create the ticket, explain what's happening and the path in the code. Feel free to close it, it may save time to someone searching on the web for No option found near ""

[Carl Eugen Hoyos]

Could you provide the complete, uncut console output to simplify reproducing the issue you see?

[Karthick Jeyapal]

We are facing this exact issue with tee muxer. Have upvoted.

[David Charbonnier]

@j_karthic you can easily patch for now search "char filename[1024];" and change it, let me know if you observe any side effect.

[Karthick Jeyapal]

@d2d22 Thanks for the reply. Exactly that is what we have done in out local branch to fix this issue(changed to 2048), and proceeded with our work. No side effects, observed so dar.
But I am not sure, if that fix is suitable for merging it upstream. Maybe we can send a patch to devel mailing list and seek maintainers' opinion.

[David Charbonnier]

@j_karthic if you want to try, go for it. It's not a good solution but a good solution seams quite complicated and require someone with a deep understanding of ffmpeg.

[Marton Balint]

Patch sent to ffmpeg-devel to fix that in AVFormatContext. Some muxers will still need updates to support filenames longer than 1024 chars, as in many cases fixed 1024 byte buffers for filenames are used.

[Elon Musk]

This one have been deprecated and replaced by *url in fa8308d3d4f27d6fb38ac2069887a7b259f1c6ab.