Hi, On Wed, Apr 6, 2011 at 11:03 PM, Stefano Sabatini <stefano.sabatini-l...@poste.it> wrote: > On Wednesday 2011-04-06 17:13:34 -0400, Ronald S. Bultje wrote: >> On Tue, Apr 5, 2011 at 4:14 AM, Stefano Sabatini >> <stefano.sabatini-l...@poste.it> wrote: >> > On date Tuesday 2011-04-05 00:32:07 +0200, Anton Khirnov wrote: >> >> On Mon, Apr 04, 2011 at 11:21:51PM +0200, Stefano Sabatini wrote: >> > [...] >> >> > Stupid question, what's wrong with av_protocol_next()? >> >> > >> >> > And why to drop the listing of the protocol features in >> >> > show_protocols()? >> >> >> >> We're making the whole unbuffered API, including URLProtocol, private, >> >> so an external app won't have any access to members of URLProtocol. >> > >> > What's the point of it? Also this is preventing an application to >> > write a custom access protocol (not to mention this is breaking >> > backward compatibility and reducing functionality as in this patch). >> >> Cleanup, of course. It's nice to be able to list all input/output >> formats, but seriously, no external app should use this API (not this >> function specifically - the whole API), and it's better to hide it >> then. >> >> How to list them? Well, maybe we need a get_input/output_protocols() >> function that returns a pointer to char[]s. I don't really know. But >> that doesn't require access to the whole >> URLProtocol/URLContext/url_*() API. > > Another point is that an application may need to implement an ad-hoc > access protocol, this is not an hypotetical need as you can find many > of such requests in the libav-user archive. I can understand that the > API may need to be made hidden for the moment while it is reworked, > but then at some point it will be useful to make the protocol struct > public again.
Let's consider that when a real usecase arises. The hypothetical "I need a custom protocol" means it's either to embed lavf demuxers in a non-FFmpeg/Libav framework, for which AVIOContext is better suited, or for stuff that should be inside FFmpeg/Libav anyway. > Another possibility is to keep the struct public and warn the user in > big capital letters that the interface is not considered stable yet > and can break at each moment (nasty solution from the user POV but yet > better than having to copy an header in your app). Manually include url.h is still possible. In fact, all our protocol handlers do it. :-). > BTW "url" is a crappy prefix in this context and higly misleading > (they are not URL parsing routines after all), I suggest something > along the line of (ff|av)proto, the fact that most protocols deal with > urls is purely accidental. The great thing is that it's internal API now, we can fix/change it. I'd really like that. This also applies to other parts, including libavfilter, where exposing an infant API can make progress a lot slower than it should be. Ronald _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
