On Thu, May 05, 2016 at 12:29:11AM +0100, Derek Buitenhuis wrote: > On 5/4/2016 11:58 PM, Thierry Foucu wrote: > >> Can i ask why it cannot be part of the public API? > > See answer below. > > >> It was really practical just to register new prefix, specially, when you > >> have to create X number of them. > > It's not harder to do via AVIO callbacks in actual code using > the API, to be honest, which already exists. To me it actually seems, > from an API user point of view, to be much clunkier to register > an external protocol and gave to craft custom URLs to trigger it, > instead of using one's own IO callbacks in the first place. > > >> I think this should be a feature. We allow to register filter, codec, > >> muxer/demuxer, why not URL > > Registering any of those was also never part of public API or allowed by the > API, since, for example, to register a new codec, you need to fill out some > fields, which require non-public headers to fill in properly. I believe > the intent was to runtime registration of only certain codecs, returned > from the other API funcs itself. I'm not sure how you would implement > an external version of any of these without cannibalizing a bunch of > internal headers.
It was possible to write and register external protocols, codecs, (de)muxers,... in the distant past. > > >> Do you have an example how to do it? How to register my_open, my_read, > >> my_seek ? > > It's an API feature, documented in avio.h: > https://ffmpeg.org/doxygen/trunk/avio_8h.html#a853f5149136a27ffba3207d8520172a5 > > An simple example can be see here: > https://github.com/dwbuiten/d2vsource/blob/master/src/core/decode.cpp#L407 > > Granted, that C++ code is pretty bad, and I am ashamed to have written it, > but it should demonstrate a little bit of how to do it. I'm sure maybe > projects > like MPV have better examples. > > > here is why I think it is nice to be able to register your own protocol: > > You can create a new binary, using ffmpeg.c as main core, but register your > > own protocol, so, you have the same command line as ffmpeg, but with your > > protocol in it > > > > For example, i can have something like this: > > > > #include "myprotocol.h" > > #define main ffmpeg_main > > #include "libavformat/url.h" > > #include "ffmpeg.c" > > #undef main > > > > int main(int argc, char **argv) { > > ffurl_register_protocol(&protocol_1); > > ffurl_register_protocol(&protocol_2); > > > > return ffmpeg_main(argc, argv); > > } > > > > > > With this binary, i will have the same command line as ffmpeg, but will > > also support any protocol i want. > > > > How can we do that without this function? > > You will not find any support here for such things, I think. > > This is quite a hack, and we should not add new APIs to support it, in > my opinion. I think you will have a hard time finding support in an open > source project for adding or re-adding APIs to make internal forks easier > to maintain (and it is an internal fork as far as I am concerned; it must > cannibalize internal headers and APIs to implement these). I understand > your plight from a maintenance point of view for existing internal code, > but I don't think this is the sort of thing to burden a widely used open > source API with. I have a hard time thinking of any other use cases for > such a program. i always liked to allow and support "Plugins" / externally registering stuff, but my oppinion on that is the minority AFAIK to me having all the stuff in internal APIs feels a bit like "lock-in" used by evil non free sw companies. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
