[FFmpeg-devel] [PATCH] lavfi/vf_libvmaf: update to use libvmaf v1.3.9

Paul B Mahol onemda at gmail.com
Mon Aug 20 20:09:49 EEST 2018

On 8/20/18, Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
> 2018-08-20 7:15 GMT+02:00, Gyan Doshi <gyandoshi at gmail.com>:
>> On 20-08-2018 03:17 AM, Carl Eugen Hoyos wrote:
>>> I believe that if a general option exists (as in this case), it is a bad
>>> idea to have a specifically targeted option that has to be used instead.
>> The user may not want the thread pool to be available for any other
>> threaded filters in the graph.
> I wonder if this is really useful (and especially if the cost of having
> an additional option for the user to know is really worth this tiny
> advantage).
> The more I think about it, the more it is obvious to me that 1) the
> filter should use the default thread number for all filters and that 2)
> an option may be specified to overwrite this number (if this is really
> needed).

Both cases are already present. Please learn to read and understand

>> Encoding/decoding threads can have stream specifiers suffixed to
>> limit scope. The filter_[complex_]threads options don't.
> Ok.
>>>> We have -filter_complex_threads for that, so no.
>>> For which use-case is this an advantage?
>> For when the intended recipient is a complex filtergraph.
> For which use-case is it an advantage that there is not one
> option to tell the filter-chain the number of threads to use,
> no matter if it is a simple or a complex filter-chain, but to
> have one option to use for the simple and a different option
> for the complex case?

Again, there is already option, please consult documentation.

This filter does not use lavfi threads so it should not use lavfi
threads option.

More information about the ffmpeg-devel mailing list