[FFmpeg-devel] configure: libvmaf requires pthreads

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.
---
 configure | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

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

> ---
>  configure | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/configure b/configure
> index 51e43fbf66..21b8cae0c3 100755
> --- a/configure
> +++ b/configure
> @@ -6425,7 +6425,8 @@ enabled libtwolame        && require libtwolame twolame.h twolame_init -ltwolame
>  enabled libuavs3d         && require_pkg_config libuavs3d "uavs3d >= 1.1.41" uavs3d.h uavs3d_decode
>  enabled libv4l2           && require_pkg_config libv4l2 libv4l2 libv4l2.h v4l2_ioctl
>  enabled libvidstab        && require_pkg_config libvidstab "vidstab >= 0.98" vid.stab/libvidstab.h vsMotionDetectInit
> -enabled libvmaf           && require_pkg_config libvmaf "libvmaf >= 1.5.2" libvmaf.h compute_vmaf
> +enabled libvmaf           && require_pkg_config libvmaf "libvmaf >= 1.5.2" libvmaf.h compute_vmaf &&
> +                             { enabled pthreads || die "ERROR: libvmaf requires pthreads"; }
>  enabled libvo_amrwbenc    && require libvo_amrwbenc vo-amrwbenc/enc_if.h E_IF_init -lvo-amrwbenc
>  enabled libvorbis         && require_pkg_config libvorbis vorbis vorbis/codec.h vorbis_info_init &&
>                               require_pkg_config libvorbisenc vorbisenc vorbis/vorbisenc.h vorbis_encode_init
> -- 
> 2.25.1
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

On 13.11.2020 02:05, lance.lmwang@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.

On Fri, Nov 13, 2020 at 02:14:05AM +0100, Timo Rothenpieler wrote:
> On 13.11.2020 02:05, lance.lmwang@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?

> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

On 13.11.2020 02:23, lance.lmwang@gmail.com wrote:
> On Fri, Nov 13, 2020 at 02:14:05AM +0100, Timo Rothenpieler wrote:
>> On 13.11.2020 02:05, lance.lmwang@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.

On Fri, Nov 13, 2020 at 01:20:57PM +0100, Timo Rothenpieler wrote:
> On 13.11.2020 02:23, lance.lmwang@gmail.com wrote:
> > On Fri, Nov 13, 2020 at 02:14:05AM +0100, Timo Rothenpieler wrote:
> > > On 13.11.2020 02:05, lance.lmwang@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.

> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

On 11/13/2020 11:27 AM, lance.lmwang@gmail.com wrote:
> On Fri, Nov 13, 2020 at 01:20:57PM +0100, Timo Rothenpieler wrote:
>> On 13.11.2020 02:23, lance.lmwang@gmail.com wrote:
>>> On Fri, Nov 13, 2020 at 02:14:05AM +0100, Timo Rothenpieler wrote:
>>>> On 13.11.2020 02:05, lance.lmwang@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.

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-request@ffmpeg.org with subject "unsubscribe".
>

James Almer (12020-11-13):
> This results in a libavfilter binary that links to libvmaf for no reason,
> potentially bloating it if it was linked statically.

That is not how static linking works. Static linking takes in the
library exactly the object files required by the binary and other
object files, nothing more. We could have -lqt -lwebkit2gtk on the link
command, the linker would just observe that nothing in them is needed
and ignore them.

By the way, if the objections I got against merging the libraries (I
don't remember exactly from whom) were based on this kind of
misconception, it would be a good idea to revise them.

On the other hand, it makes a difference with dynamic linking: the
binary would be unable to run without the shared library present.

Regards,

On Fri, Nov 13, 2020 at 11:34:09AM -0300, James Almer wrote:
> On 11/13/2020 11:27 AM, lance.lmwang@gmail.com wrote:
> > On Fri, Nov 13, 2020 at 01:20:57PM +0100, Timo Rothenpieler wrote:
> > > On 13.11.2020 02:23, lance.lmwang@gmail.com wrote:
> > > > On Fri, Nov 13, 2020 at 02:14:05AM +0100, Timo Rothenpieler wrote:
> > > > > On 13.11.2020 02:05, lance.lmwang@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-request@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-request@ffmpeg.org with subject "unsubscribe".

On 11/13/2020 11:40 AM, Nicolas George wrote:
> James Almer (12020-11-13):
>> This results in a libavfilter binary that links to libvmaf for no reason,
>> potentially bloating it if it was linked statically.
> 
> That is not how static linking works. Static linking takes in the
> library exactly the object files required by the binary and other
> object files, nothing more. We could have -lqt -lwebkit2gtk on the link
> command, the linker would just observe that nothing in them is needed
> and ignore them.

I thought that was -lto behavior.

> 
> By the way, if the objections I got against merging the libraries (I
> don't remember exactly from whom) were based on this kind of
> misconception, it would be a good idea to revise them.

Don't think they were.

> 
> On the other hand, it makes a difference with dynamic linking: the
> binary would be unable to run without the shared library present.
> 
> Regards,
> 
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>

James Almer (12020-11-13):
> I thought that was -lto behavior.

No, I am sure of what I am saying about classic static libraries. I do
not know link-time optimizations very well, but I suspect they relate to
optimizing withing a single object file.

> Don't think they were.

I strongly suspect some of them were.

Regards,