On 2018/03/25 16:21, Michael Niedermayer wrote:
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.
Sure, if someone else reverts, designs, write, integrates, deals with
the never-ending bikeshedding, fixes issues around lavf/lavd's broken
shit, why not? But that's not going to happen, let's be real. If anyone
actually cared enough, then it would be fixed already. It's been broken
since version 0.5, the only reason people care now is because they're
scared of change. It may not be the 'best' API, but if everything was
designed the 'best' then we wouldn't have to deal with stuff like this.
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.
What size explosion?
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.
I honestly would like to be an idealist here, but it's much more
practical to just be real here. Nothing happens in this project unless
the conversation begins with a patch (and even then, stuff barely
happens). So in the words of others on the list:
You forgot to attach your patch.
--
Josh
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
