Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#3024 closed defect (fixed)

ffplay do not keep custom http headers across http sessions playing m3u8

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

Description

FFmpeg version:
ffmpeg version N-56778-gcd1b22d

Summary of the bug:
Attempting to use ffplay to play a remote m3u8 stream the http custom headers are used one time just to download the m3u8 mainfest.
Next, when downloading the hls chunks the http custom headers are lost.
The user-agent, instead, is kept across all the http sessions.
How to reproduce:
ffplay -user-agent 'Linux' -headers $'X-Forwarded-For: 185.186.145.47\r\n' http://rm-edge-4.cdn2.streamago.tv/streamagoedge/1922/815/playlist.m3u8

Attachments (2)

xfor.log (1.8 KB ) - added by Kow 8 years ago.
Log summary showing only the first http request using a custom header
hls.c (28.2 KB ) - added by Kow 8 years ago.
hls.c patched to keep user header during the whole hls streaming

Download all attachments as: .zip

Change History (7)

by Kow, 8 years ago

Attachment: xfor.log added

Log summary showing only the first http request using a custom header

comment:1 by Kow, 8 years ago

Summary: ffplay do not keep custom http headers within http sessions playing m3u8ffplay do not keep custom http headers across http sessions playing m3u8

comment:2 by Carl Eugen Hoyos, 8 years ago

Component: FFplayundetermined
Keywords: hls added
Priority: importantnormal
Resolution: duplicate
Status: newclosed
Version: unspecifiedgit-master

Looks like a duplicate of ticket #1291, please test again once it is fixed.

comment:3 by Kow, 8 years ago

It is similar but not exactly the same. The user-agent is correcty kept across all the http sessions (getting the initial manifest and the following chunk download) but not the the -header content.
I understand nothing about C programming but it seems that the hls.c looking about info to broker thru the whole bunch of sessions takes care of the user-agent and cookies only, if I'm not wrong.
I've fixed for myself by hardcoding into http.c my header:

static int http_connect(URLContext *h, const char *path, const char *local_path,

const char *hoststr, const char *auth,
const char *proxyauth, int *new_location)

{

HTTPContext *s = h->priv_data;
int post, err;
char headers[4096] = "X-Forwarded-For: xxx.186.xxx.xxx\r\n";
char *authstr = NULL, *proxyauthstr = NULL;
int64_t off = s->off;
int len = 0;
const char *method;

but I know it it just a specific workaround to fit my needs.

Tanks for your attention.

Last edited 8 years ago by Kow (previous) (diff)

by Kow, 8 years ago

Attachment: hls.c added

hls.c patched to keep user header during the whole hls streaming

comment:4 by Kow, 8 years ago

We have patched hls.c to solve the user header lost during http connections.
It works fine for me now.

comment:5 by Carl Eugen Hoyos, 8 years ago

Component: undeterminedavformat
Resolution: duplicatefixed

Fixed by you in 4684539c - thank you!

Note: See TracTickets for help on using tickets.