On 06.02.2016 18:55, wm4 wrote: > On Sat, 6 Feb 2016 18:46:59 +0100 > Andreas Cadhalpun <andreas.cadhal...@googlemail.com> wrote: >> You're not constructive. > > Even if that is true, neither are you.
I try to be constructive. The problem is that all proposed alternative ways (change VLC to use one thread for hwaccel and fall back to more threads if hwaccel fails; make libavcodec do this automatically) are rather difficult to implement. While I would prefer such a solution, it can't be used until it exists. > You want to revert a change that > was often discussed and found to be the best way to go about the issue, No, this is not the best way. libavcodec automatically doing the right thing would be. > just because it's the way of least resistance for you. I don't think arguing with you can be called 'way of least resistance'. > While we normally would very much try not to break API users, including > VLC, this case has a bit of a history. Don't forget the behavior of the > VLC dev, who was never constructive about this either. On the Libav > side he AFAIK kept claiming it was not his problem. When the change was > made on the FFmpeg side, he just changed the VLC configure script to > reject FFmpeg, instead of bringing up this issue anywhere. So bad behavior of one developer justifies breaking the setup of thousands of users? >> I doubt you'd like being told that when a >> change in ffmpeg broke mpv in a similar way and couldn't easily be >> fixed there. > > I doubt I could get a debian maintainer to waste the time of FFmpeg > developers just because I don't want to adapt in a specific case. Just don't waste the time and become constructive. Best regards, Andreas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
