On Sun, Jun 20, 2010 at 07:35:40PM +0300, Martin Storsjö wrote: > 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
uhm hmm :(
a hair of hackery that would solve this is to set next=1 on all of
ours and
malloc() + copy if its not so in register under #if
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Old school: Use the lowest level language in which you can solve the problem
conveniently.
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.
signature.asc
Description: Digital signature
_______________________________________________ FFmpeg-soc mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
