[FFmpeg-devel] [FFmpeg-cvslog] Merge commit '2758cdedfb7ac61f8b5e4861f99218b6fd43491d'

[Derek Buitenhuis]

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