[FFmpeg-soc] [PATCH] rtsp tunneling

[Michael Niedermayer]

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

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/attachments/20100616/5b85a411/attachment.pgp>