[FFmpeg-soc] [PATCH] http refactoring

[Josh Allmann]

On 2 June 2010 00:01, Martin Storsjö <martin at martin.st> wrote:
> On Tue, 1 Jun 2010, Josh Allmann wrote:
>
>> On 1 June 2010 15:22, Josh Allmann <joshua.allmann at gmail.com> wrote:
>> >
>> > The first patch separates the initialization from the actual
>> > connection, which will enable delayed connections using the internal
>> > api.
>> >
>>
>> Ignore this one (for now).
>>
>> It  works within http.c, but not outside (eg, with rtsp) because
>> there's no way to initialize the URLContext without calling url_open
>> and hence http_open. Making http_open do delayed connections by
>> default will break API behavior.
>
> Exactly. What about making it work just as it does now, but adding e.g.
> some URL_DELAYOPEN flag, which changes its behaviour, which iirc Ronald
> suggested. Then you can do a normal url_open(..., URL_DELAYOPEN), set the
> custom headers and then open the actual connection?
>

That works too (although I must have missed Ronald's suggestion). It's
similar to something I suggested earlier on IRC, but I wanted to name
it URL_RTSP or something. I will take a look at that in the morning,
since it's simpler than my other solution, I'm sending another patch
anyway for posterity because I just finished it.

The patch splits url_open into ff_url_open which does the detection of
the protocol handler and allocates the URLContext.

url_open_protocol is likewise split into alloc_url (called from
ff_url_open), which does what it sounds. This actually breaks API by
only allocating on a null handler, which I need to check to avoid
allocating twice when calling from url_open. I can probably fix this
after some sleep.

> Also, as for replacing/adding headers.. I'm not sure that you'd want to
> skip all of the default headers if you're adding custom ones, e.g.
> User-Agent, Accept and Host can very well be kept, perhaps Connection:
> close, too.
>
> Ideally, the user code should be able to remove/replace these headers if
> it wants to, but use the default values if nothing is changed. But that
> requires a bit more complex data structure... Perhaps that's out of scope
> here, too.

Agreed, it will take quite a bit of work. The current method is
quick-n-dirty, but functional.

It might be a good idea to introduce some more flexibility into this
anyway -- I still haven't built a way to disable chunked encoding.
Another small ff_http method setting a context flag will do the trick,
but if we want to build something a little more flexible for all this,
now is the time to do it. AVOptions maybe?

Josh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 003_separate_url_init.diff
Type: text/x-patch
Size: 3397 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/attachments/20100602/e9600f80/attachment.bin>