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.
_______________________________________________
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".
