[FFmpeg-devel] [PATCH] avdevice/avdevice: Deprecate AVDevice Capabilities API

Nicolas George george at nsup.org
Mon Jan 25 19:42:16 EET 2021


James Almer (12021-01-25):
> And that's why we're trying to merge them. So again, a subdirectory is not
> obligatory for this purpose, and alternative suggestions are welcome.
> Even just saying to keep them in the root folder would be more useful than

That is what leaving it alone implies.

> saying "Work on something else".

As a general principle, I think no member of this project should touch
an area of the code they hate: hate is not compatible with good work. Do
you not agree?

> Saying and thinking that lavd devices with their current capabilities and
> API are not very useful is not being "dismissive of other people's efforts",
> it's giving his opinion.

But saying it is "worse than useless" is dismissive. Double standards.

> Mark then suggested to directly replace/extend the API with one that's more
> useful in the long run, instead of removing them as Anton suggested since
> you and some other devs stated they in fact do have users, and you agreed to
> that. So how about we try to move in that direction? The first step is
> merging the libraries, and not trying to stop any relevant effort.

No. The first step is to acknowledge that libavdevice is useful, already
as it is. I am still waiting for that.

The second step would be to think about how it can be made even more
useful. For that, we need people who understand its usefulness. People
who do not should stay out of it, or at least take second role.

I have detailed thoughts on making libavdevice much more useful. And
they do not involve merging with libavformat; and they require a few
infrastructure steps before they can happen. But I will not discuss them
in this hostile environment, as a defense. If somebody is interested and
sympathetic, I will gladly explain them.

> And for that matter, unlike you, Anton did not resort to ad hominem attacks
> to back his argument.

Unfortunately, this point is significant of a wider attitude towards
features versus purity. It needs to be addressed or the project will
wither.

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/20210125/043de62f/attachment.sig>


More information about the ffmpeg-devel mailing list