[FFmpeg-devel] [RFC] Add option for using PUT instead of POST in HTTP protocol
Mon Aug 2 16:47:21 CEST 2010
On Mon, 2010-08-02 at 11:25 +0200, Stefano Sabatini wrote:
> On date Saturday 2010-07-31 10:50:54 +0300, Martin Storsj? encoded:
> > On Fri, 30 Jul 2010, Tomas H?rdin wrote:
> > > I've mentioned a couple of times on this list that users might want to
> > > use PUT to upload files instead of POST. As expected, I had to do that
> > > at work today. I solved it using a simple hack, but after asking around
> > > a bit on IRC it seems implementing this as an option in http's priv_data
> > > would be an acceptable solution.
> > >
> > > As a proposal, I added an int called "put" in HTTPContext, and a
> > > corresponding AVOption. If non-zero, it uses "PUT" instead of "POST" for
> > > uploads. See attached patch, although it's just for discussion purposes
> > > since I'm not entirely sure how to use AVOption. It compiles and tests
> > > fine though.
> > Looks sensible to me.
> > As said on irc, I'm a bit weary of adding options that aren't used by code
> > within ffmpeg, but this looks simple enough, so I think this could be
> > acceptable, once you've tested this to work in the environment you want to
> > use it in.
> Looks acceptable to me, but we should have a mechanism to set these
> options from the ff* applications.
Maybe also a way to list them, like in the -protocols list?
> That may work like this:
> ffmpeg -proto_opts="chunksize=1234:method=POST" -i http://www.samples.org/mysample.ogg out.nut
Looks reasonable enough. I might post a patch doing something like that
when my vacation is up, which is a week away. I'll be gone until then.
> In general allowing a protocol/muxer/demuxer/... element to have a
> private context is a clever move (rather than having a huge catch-all
> context like currently implemented for codecs/muxdemuxers).
> Note that we have already code which can be used to achieve this, in
> particular opt.[hc] and libavfilter/parseutils.h:av_set_options_string().
> opt.[hc] should be made more general and moved to lavu or lavcore
> (Michael mentioned that he's working to something related to that?),
> then av_set_options_string() should be moved accordingly.
> In the meaninghwile we should start to document such private options,
> doc/protocols.texi badly needs docs for the HTTP protocol, patches for
> that are welcome.
Good idea. Probably better than sticking it in some random installed
header, which is what I was thinking about at first.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: This is a digitally signed message part
More information about the ffmpeg-devel