[FFmpeg-devel] [PATCH v4 3/7] cmdutils: use new iteration APIs

[Nicolas George]

Josh de Kock (2018-03-22):
> move lavd avinputformats and avoutputformats into lavf
> 
> delete lavd

Possibly ok in principle for me, but see below.

> write new lavd aimed at actual devices

There are already such libraries, we do not need another. The basic
devices with a (de)muxer API are quite right to give many extra features
with little extra cost.

But why are we discussing this? It seems to me that the discussion went
approximately like this:

"Darn, the faucet I just bought to fix the leaky one does not fit the
pipes. Well, I guess I will have to redo the whole plumbing to make it
fit."

The correct way of addressing the problem is to buy a new faucet with
the correct size. And cut the losses if the first one cannot be
refunded. I feel like the discussion is largely fueled by the cognitive
bias known as "sunk cost fallacy": due to efforts invested in a
solution, become attached emotionally to it and fail to see when it
proves to cause more costs than benefits.

Can we at least REALLY CONSIDER this:

1. Acknowledge that this issue about lavd, on top of Michael's early
   concerns about registering external components, has proven that the
   all-static approach, while elegant in many ways, is not practical.

2. Agree to revert the API as it is and discuss a better solution.

3. As for the better solution, I really propose to register the
   components (with av_register_something calls, like now) into an array
   rather than a linked list (like your proposal) that is stored in a
   user-provided structure that can exist in several instances (new),
   with a global instance of that structure for temporary compatibility.

Note that with this proposal, your efforts are not wasted: most of the
code can be reused, and they have taught us a valuable lesson on top of
that.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180323/8be6df1c/attachment.sig>