[FFmpeg-soc] [PATCH] http refactoring

Martin Storsjö martin at martin.st
Wed Jun 2 10:18:19 CEST 2010


On Wed, 2 Jun 2010, Josh Allmann wrote:

> On 2 June 2010 00:01, Martin Storsjö <martin at martin.st> wrote:
> > On Tue, 1 Jun 2010, Josh Allmann wrote:
> >
> >> 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.

Yes, but I don't think such a flag would be accepted, since it doesn't 
have any meaning at all for other protocols, while a URL_DELAYOPEN flag 
very well could be useful for other protocols, too.

> > 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?

I think ff_http_* functions for setting both custom headers and disabling 
chunked transfer-encoding is ok for now, otherwise you'll end up 
refactoring way too much without getting ahead at the actual task at hand.

// Martin


More information about the FFmpeg-soc mailing list