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

[Michael Niedermayer]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160505/eb4e3d30/attachment.sig>