On Fri, Mar 23, 2018 at 11:05:22AM +0100, Nicolas George wrote: > 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. iam in favor of reverting the API, there is apparently discussion going on now here to design a different, better API and IMHO its better not to introduce a new API now if there is active work going on to change it. People would just start to switch to the current API only to have it deprecated in the release after that and having to replace it again If the new API stays then I will most likely have to submit some ugly hack to workaround the size explosion issue for static linking with the current API. And that for each lib not just avcodec. Thats to allow the ffmpeg ossfuzz code to grow and test more things quickly within the available resources. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel