Opened 4 months ago

Last modified 3 months ago

#6856 open defect

filename limited to 1024

Reported by: d2d22 Owned by: cus
Priority: normal Component: undetermined
Version: unspecified Keywords:
Cc: cus 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 (10)

comment:1 Changed 4 months ago by cehoyos

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 Changed 4 months ago by d2d22

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 months ago by d2d22 (previous) (diff)

comment:3 Changed 4 months ago by cehoyos

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

comment:4 Changed 4 months ago by d2d22

  • Resolution set to invalid
  • Status changed from new to closed

comment:5 Changed 4 months ago by cehoyos

  • Resolution invalid deleted
  • Status changed from closed to reopened

comment:6 Changed 4 months ago by j_karthic

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

comment:7 Changed 4 months ago by d2d22

@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 Changed 4 months ago by j_karthic

@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 Changed 4 months ago by d2d22

@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 Changed 3 months ago by cus

  • Cc cus added
  • Owner set to cus
  • Status changed from reopened to open

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.

Note: See TracTickets for help on using tickets.