Hi, On Mon, Mar 11, 2019 at 4:53 AM Moritz Barsnick <barsn...@gmx.net> wrote:
> On Mon, Mar 11, 2019 at 01:59:47 +0100, Carl Eugen Hoyos wrote: > > The library needs non-free in configure and please > > use dynamic linking, not loading at run-time. > > There is also no indication whatsoever where to get mvM264Ffmpeg.dll > and libmvM264Ffmpeg.so from. No-one can even attempt to run (or - once > you, Yufei, have fixed it - compile) this functionality without this. > That's hopeless. > I want to reiterate my point from the other thread here that I think it's time that we set an official project policy w.r.t. closed-source software. I believe we should either choose that there is no place in FFmpeg for this sort of things (I support this point of view), or we should set specific guidelines about the software (I understand some developers lean more towards this, and I respect that). Right now it's all random and that's not good. - How do we set up a fate station with m264 support? Or will matrox provide one? Or will it be available to FFmpeg developers at no charge? - How do we test that it still works after we make innocent changes to some API? - If we add new H264 files to our conformance suite, how do we confirm that m264dec passes them? - If we see particular optimizations or code changes that would make this wrapper work better, how do we test that it still works? (If we can't, then is the wrapper truly open source software?) Etc. Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
