[FFmpeg-soc] [PATCH] rtsp tunneling

[Martin Storsjö]

On Wed, 16 Jun 2010, Michael Niedermayer wrote:

> On Wed, Jun 16, 2010 at 10:47:03PM +0300, Martin Storsjö wrote:
> > On Wed, 16 Jun 2010, Michael Niedermayer wrote:
> > 
> > > On Wed, Jun 16, 2010 at 07:51:32PM +0300, Martin Storsjö wrote:
> > > > On Wed, 16 Jun 2010, Michael Niedermayer wrote:
> > > > 
> > > > > On Mon, Jun 14, 2010 at 08:12:30PM +0300, Martin Storsjö wrote:
> > > > > > 
> > > > > > Additionally, as far as I've understood AVOptions, they can only set 
> > > > > > something within one struct, since it simply uses offsets. For this case, 
> > > > > > we'd need AVOptions that would only apply if the URLContext happens to be 
> > > > > > a HTTP context, and then set the options within the priv_data, which can't 
> > > > > > be done as a simple offset (unless the priv_data is tacked on at the 
> > > > > > end of the context...)
> > > > > 
> > > > > I think we should check the past discussion about using AVOptions and private
> > > > > contexts. but from memory
> > > > > Adding an AVClass pointer to URLProtocol (and a priv_data_size of course too)
> > > > > allows us to allocate and init to defaults the private context in generic code
> > > > 
> > > > Not as far as I understand it. In libavcodec/opt.c, for example 
> > > > av_set_number2, lines 63-70, store values using this logic:
> > > > 
> > > >     dst= ((uint8_t*)obj) + o->offset;
> > > >     *(int*)dst= llrint(num/den)*intnum;
> > > > 
> > > > So the only things it can express are storing values with a plain offset 
> > > > from the start of the object. There's no code for dereferencing the 
> > > > priv_data pointer and using that as an object.
> > > > 
> > > > In order to set values within the private data, we'd need to make the 
> > > > private data an AVClass so that it can have different options depending on 
> > > > what the actual protocol is. Then in the generic AVClass for URLContext, 
> > > > we'd need to store the offset of the private data pointer, so that the 
> > > > generic AVOption code can check for options in the private data if the 
> > > > option wasn't found in the generic URLContext.
> > > 
> > > The user code that calls av_set_number2() can just check if it failed and
> > > callit on priv_data
> > > not saying this is better, iam just saying that the extension you hint at is
> > > not strictly needed
> > 
> > Hmm, true, that would perhaps simplify things a bit. But even then, we'd 
> > need a way to know whether priv_data actually contains an AVClass or not. 
> > Either we'd mandate such a member for all protocols' priv_data, or add 
> > some flag somewhere in URLContext, e.g. priv_data_has_class.
> 
> id mandate it but allow it to be NULL

Thanks, then it should be quite straightforward to implement.

What modifications to URLProtocol are allowed without requiring a major 
bump? Since we've got a public function av_register_protocol that takes an 
URLProtocol*, doesn't even a simple addition of new fields require a major 
bump, since external apps could register their own URLProtocols? Despite 
this, the last lavf major bump was in November 2007, but three new fields 
have been added to URLProtocol since that.

If not, the rest of this should be quite easy.

// Martin