[FFmpeg-devel] [PATCH 0/4] avdevice/dshow: implement capabilities API

[Nicolas George]

Anton Khirnov (12021-06-09):
> > > There is no timeline, it depends on someone sitting down and doing the
> > > work. The options proposed so far were
> > > 1) merging libavdevice into libavformat
> > > 2) making libavdevice into an independent library with an independent
> > >    API
> > > 3) moving libavdevice functionality into ffmpeg.c
> > Thanks for providing the explored options. What problem is there in
> > the way things currently are that these would be solving?
> The problem is that libavdevice is a separate library from libavformat,
> but fundamentally depends on accessing libavformat internals.

Point 3 is just completely unacceptable, as there are applications using
libavdevice. Please do not mention it again unless you have new strong
arguments about it.

As for point 2, I explained at the time (but for some reason you
neglected to mention it) that it was a false good idea. Of course,
libavdevice is not the same thing as libavformat, and therefore it's
obvious they should have different APIs to reflect their specificity.

But obvious does not mean true. If we have learned something from
object-oriented programming, it's that similar APIs should be merged,
not split, so that objects that share common properties can be
transparently used with the same code path.

If somebody were to make a separate API for libavdevice, the only result
would be that all code would ceaselessly go trough compatibility
wrappers. A pure waste of time.

Here too, if you ever mention it again, please take this argument into
consideration.

As for point 1, it would be nice to be able to use ff_* functions rather
than the avpriv_* hacks. But unless you realize that it should not apply
to libavformat/libavdevice but to all the libraries in ffmpeg, let me
tell you it is not an efficient use of your time.

Still, if you want to use your time inefficiently and turn
libavformat+libavdevice into a single linking unit, probably named
libavformat, then I have no objection since it is a small step into the
right direction.

OTOH, please do not touch the directory structure, as it would be
annoying and bring no benefit.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20210611/3ea76a14/attachment.sig>