On Fri, Nov 13, 2020 at 11:34:09AM -0300, James Almer wrote: > On 11/13/2020 11:27 AM, lance.lmw...@gmail.com wrote: > > On Fri, Nov 13, 2020 at 01:20:57PM +0100, Timo Rothenpieler wrote: > > > On 13.11.2020 02:23, lance.lmw...@gmail.com wrote: > > > > On Fri, Nov 13, 2020 at 02:14:05AM +0100, Timo Rothenpieler wrote: > > > > > On 13.11.2020 02:05, lance.lmw...@gmail.com wrote: > > > > > > On Thu, Nov 12, 2020 at 05:56:57PM +0100, Timo Rothenpieler wrote: > > > > > > > Technically, libvmaf itself does not, but our filter does, and > > > > > > > there is > > > > > > > no other sensible way to prevent a build with --enable-libvmaf > > > > > > > from > > > > > > > succeeding while not actually enabling the filter. > > > > > > > > > > > > If it's private filter, I think you it's better to add the pthread > > > > > > depends for your filter > > > > > > only, search for libvmaf_filter_deps > > > > > > > > > > The filter already depends on pthreads correctly. > > > > > This is about the issue where you can produce a build that is > > > > > configured > > > > > with --enable-libvmaf, but which does not have the libvmaf filter. > > > > > > > > > > Happens for example on Win32, where w32threads are used by default. > > > > > > > > so it doesn't work with --enable-pthreads also? > > > > > > Of course it does, but there is no indication for that to the user > > > whatsoever. > > > And given that there is only that one consumer of --enable-libvmaf, the > > > libvmaf filter, which also depends on pthreads, adding an error like this > > > seems appropriate to inform users about the pthread requirement. > > > > But libvmaf library itself does not depend on pthread, so if libvmaf filter > > is used, it'll depend pthread by libvmaf_filter_deps. I'm not sure why the > > deps doesn't working as expected as I can't test win32 system. > > The point here is that, if a user configures with --enable-libvmaf but > doesn't have pthreads, the library will be enabled but the filter will not. > This results in a libavfilter binary that links to libvmaf for no reason, > potentially bloating it if it was linked statically.
This make senses, thanks for the explanation. > > Since we have no other module using libvmaf, we can simply make libvmaf > itself dependent on pthreads. This way --enable-libvmaf will fail if > pthreads is not present, which is better than succeeding but ultimately not > compiling the filter as the user clearly wanted by passing the above option. > > > > > > _______________________________________________ > > > ffmpeg-devel mailing list > > > ffmpeg-devel@ffmpeg.org > > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > > > To unsubscribe, visit link above, or email > > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > > > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". -- Thanks, Limin Wang _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
