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. >> 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. Cheers, - Derek _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
