Opened 16 months ago

Last modified 3 months ago

#7695 new defect

ffmpeg is ignoring -headers option

Reported by: Anan5a Owned by:
Priority: normal Component: undetermined
Version: git-master Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


Summary of the bug:
Ffmpeg Ignores custom http header options supplied using -headers option
How to reproduce:

$ ffmpeg -headers 'Referer: http://gp.bioscopelive.con/' -i files/list/6st1UI3HC97_360p.m3u8
ffmpeg version : git-master
built on GCC 8 Debian 10

Change History (3)

comment:1 Changed 16 months ago by cehoyos

  • Component changed from ffmpeg to undetermined
  • Priority changed from important to normal
  • Reproduced by developer unset

This has currently no similarities with a valid ticket. Please test current FFmpeg git head - nothing else is supported here - and provide the command line you tested together with the complete, uncut console output. Please also explain why you want to provide specific html headers when reading from your file system.

comment:2 Changed 16 months ago by barsnick

I agree that the command line is bogus, for several reasons:

  • The URL given in the referer is misspelled, and therefore probably useless, because if the server really requires it, it will not validate correctly.
  • The content the reporter is likely trying to download ("Sultan: The Saviour") is probably protected by (at least) a login. I may be wrong, and it's only the video's web page which is login-protected.
  • Assuming that the m3u8 file references http(s) hls segments, recent ffmpeg's command line requires a "-protocol_whitelist" to allow loading them.

On the other hand, the report is correct in so far that it does not seem possible to give ffmpeg command line options meant for e.g. protocols triggered "underneath". I.e. ffmpeg launches with a file protocol input which promotes to hls, but this in turn may trigger http protocol segments, yet ffmpeg will refuse to accept http protocol options on the command line.

Some muxers have ways of achieving this: The tee muxer has a special syntax, the segment muxer has "-segment_format_options", the dash muxer has "-format_options", the fifo muxer has "-format_opts". I don't see this for the hls demuxer (which is used in this example) though. The hls demuxer does expose some http protocol options via its own proxy options ("-http_persistent", "-http_multiple"), but "-headers" does not belong to those.

So, this may actually be a feature request...

Last edited 16 months ago by barsnick (previous) (diff)

comment:3 Changed 3 months ago by StndCpp

I am facing the same ffmpeg limitation with the current nightly for windows (20200309-608b8a8-win64-static).
If I supply ffmpeg an input m3u file located in my hard disk there is no way to customize http headers of subsequent network requests ffmpeg will make. This is also the case if the m3u is supplied via input pipe instead of input local file (for example with cat or echo in windows).

The reasons to need this feature could be diverse, for example you could need to download an m3u file to the hard disk and edit its content before feeding it to ffmpeg, using custom headers like you could if the m3u was located on the internet.

I could provide more detailed info or commands to replicate, but I think it is already clear what this feature request is about. Still if needed, let me know.
So, is there any chance this will be implemented, or is there already a way to achieve this with ffmpeg that I am not aware?

Note: See TracTickets for help on using tickets.