[FFmpeg-devel] [PATCH] configure: libvmaf requires pthreads

[lance.lmwang at gmail.com]

On Fri, Nov 13, 2020 at 11:34:09AM -0300, James Almer wrote:
> On 11/13/2020 11:27 AM, lance.lmwang at gmail.com wrote:
> > On Fri, Nov 13, 2020 at 01:20:57PM +0100, Timo Rothenpieler wrote:
> > > On 13.11.2020 02:23, lance.lmwang at gmail.com wrote:
> > > > On Fri, Nov 13, 2020 at 02:14:05AM +0100, Timo Rothenpieler wrote:
> > > > > On 13.11.2020 02:05, lance.lmwang at 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 at ffmpeg.org
> > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > > 
> > > To unsubscribe, visit link above, or email
> > > ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
> > 
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".

-- 
Thanks,
Limin Wang