Opened 4 years ago

Closed 3 years ago

#6856 closed defect (fixed)

filename limited to 1024

Reported by: David Charbonnier Owned by: Marton Balint
Priority: normal Component: undetermined
Version: unspecified Keywords:
Cc: Marton Balint Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


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];

Change History (11)

comment:1 by Carl Eugen Hoyos, 4 years ago

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.

comment:2 by David Charbonnier, 4 years ago

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 ""

Last edited 4 years ago by David Charbonnier (previous) (diff)

comment:3 by Carl Eugen Hoyos, 4 years ago

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

comment:4 by David Charbonnier, 4 years ago

Resolution: invalid
Status: newclosed

comment:5 by Carl Eugen Hoyos, 4 years ago

Resolution: invalid
Status: closedreopened

comment:6 by Karthick Jeyapal, 4 years ago

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

comment:7 by David Charbonnier, 4 years ago

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

comment:8 by Karthick Jeyapal, 4 years ago

@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.

comment:9 by David Charbonnier, 4 years ago

@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.

comment:10 by Marton Balint, 4 years ago

Cc: Marton Balint added
Owner: set to Marton Balint
Status: reopenedopen

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.

comment:11 by Elon Musk, 3 years ago

Resolution: fixed
Status: openclosed

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

Note: See TracTickets for help on using tickets.