That line has been written by previous job.
Fix tsan warning.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

For the blue and violet noise, I took the pink and brown noise
respectively and subtracted the offsets instead of adding them. When I
eyeball the frequency spectrum of the resulting outputs it looks correct
to me, i.e. the blue graph appears to be a mirror image of the pink, and
the same can be said of the violet and the brown. I did not do anything
else to confirm the correctness.

Benchmark (with 2 cpus):
./ffmpeg -f rawvideo -s 1280x720 -t 1000 -i /dev/zero \
    -filter_threads $threads -vf transpose=clock -f null null
threads=2:
  old: 31.129s 31.446s 31.574s
  new: 29.602s 29.636s 29.656s
threads=3 (nb_threads = nb_cpus + 1 is bad choice at this situation):
  old: 40.132s 40.279s 40.279s
  new: 39.308s 39.570s 39.693s
threads=4:
  old: 31.306s 31.366s 31.654s
  new: 30.231s 30.360s 30.451s
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>

This one changes the previous vmaf patch to libvmaf to keep it separate from the
native implementation of vmaf inside ffmpeg later.
Signed-off-by: Ashish Singh <ashk43712@gmail.com>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

The scale2ref filter will now maintain the DAR of the main input and
not the DAR of the reference input. This previous behavior was deemed
counterintuitive for most (all?) use-cases.

Before:
scale2ref=iw/4:ow/mdar
in  w:320 h:240 fmt:rgb24 sar:1/1
ref w:640 h:360 fmt:rgb24 sar:1/1
out w:160 h:120 fmt:rgb24 sar:4/3 flags:0x2
SAR: ((120 * 640) / (160 * 360)) * (1 / 1) = 4 / 3
DAR: (160 / 120) * (4 / 3) = 16 / 9
(main out now same DAR as ref)

Now:
scale2ref=iw/4:ow/mdar
in  w:320 h:240 fmt:rgb24 sar:1/1
ref w:640 h:360 fmt:rgb24 sar:1/1
out w:160 h:120 fmt:rgb24 sar:1/1 flags:0x2
SAR: ((120 * 320) / (160 * 240)) * (1 / 1) = 1 / 1
DAR: (160 / 120) * (1 / 1) = 4 / 3
(main out same DAR as main in)

The scale2ref FATE test has also been updated.
Signed-off-by: Kevin Mark <kmark937@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Process more pixels per loop.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>

Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

~5-15% faster overall with main input without alpha.
Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Its been deprecated for over 3 years.
Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Fixes framesync filters with shortest option enabled.

This reverts commit 0ff5567a.

None of them are specific to the YASM assembler.

(Cherry-picked from libav commit 39e208f4)
Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

The input width and height is known at parse time so there's no
reason ow/oh should not be usable when using 0 as the width or
height expression.

Previously in "scale=0:ow" ow would be set to "0" which works,
conveniently, as "scale=0:0" is perfectly valid input but this breaks
down when you do something like "scale=0:ow/4" which one could
reasonably expect to work as well, but does not as ow is 0 not the
real value.

This change handles the 0 case for w/h immediately so the ow/oh
variables work as expected. Consequently, the rest of the code does
not need to handle 0 input. w/h will always be > 0 or < 0.

The second explicit (int) cast ensures that ow/oh appear as integers
as a user might expect when dealing with pixel dimensions.
Signed-off-by: Kevin Mark <kmark937@gmail.com>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>