[FFmpeg-devel] [PATCH] Rudimentary cookie support for HTTP

Duncan Salerno duncan.salerno at gmail.com
Wed Oct 10 23:33:49 CEST 2012


On Wed, Oct 10, 2012 at 4:16 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Tue, Oct 09, 2012 at 09:09:58PM +0100, Duncan Salerno wrote:
>> For comment. The aim is primarly for HLS (and I guess later HDS) where a request to an initial URL sets some cookies, which are required in later requests as authentication. There is no need for cookies to persist across runs of ffmpeg.
>>
>> However with this implementation cookies are never free'd - is this okay? Any better suggestions?
>> ---
>>  libavformat/http.c |   62 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 62 insertions(+)
>>
>> diff --git a/libavformat/http.c b/libavformat/http.c
>> index d385011..ef6f296 100644
>> --- a/libavformat/http.c
>> +++ b/libavformat/http.c
>> @@ -87,6 +87,18 @@ static const AVClass flavor ## _context_class = {\
>>  HTTP_CLASS(http);
>>  HTTP_CLASS(https);
>>
>> +
>> +/**
>> + * Store cookies in a linked list.
>> + */
>> +typedef struct Cookie {
>> +    const char *domain;                 ///< domain
>> +    const char *path;                   ///< path
>> +    const char *value;                  ///< cookie name value pair (ie. name=value)
>> +    struct Cookie *next;                ///< next Cookie
>> +} Cookie;
>
>> +static Cookie *cookiejar = NULL;
>
> this is not thread safe, there can be multiple independant http
> protocols open, they might in theory on a server even belong to
> different users (imaging a web app that downloads & encodes videos
> and is run from a single process with multiple threads one per user)

Could you suggest a better way? For example, in the case of HLS, I was
thinking about storing the cookie jar in that context, but it doesn't
control the original HTTP.request, so how could it get cookies set in
the initial response?


More information about the ffmpeg-devel mailing list