FFmpeg already tests for this case in configure_output_filter() and printed a
clearer error message
example:
./ffmpeg -f lavfi -i color -f lavfi -i color -filter_complex "[1]null[x],[0][1]overlay" -f null -
before the merge / after the revert:
Filter null has a unconnected output
after the merge / before the revert:
Output pad "default" with type video of the filter instance "Parsed_null_0" of null not connected to any destination
Error configuring complex filters.
Invalid argument
avutil/mathematics: speed up av_gcd by using Stein's binary GCD algorithm
This uses Stein's binary GCD algorithm:
https://en.wikipedia.org/wiki/Binary_GCD_algorithm
to get a roughly 4x speedup over Euclidean GCD on standard architectures
with a compiler intrinsic for ctzll, and a roughly 2x speedup otherwise.
At the moment, the compiler intrinsic is used on GCC and Clang due to
its easy availability.
Quick note regarding overflow: yes, subtractions on int64_t can, but the
llabs takes care of that. The llabs is also guaranteed to be safe, with
no annoying INT64_MIN business since INT64_MIN being a power of 2, is
shifted down before being sent to llabs.
The binary GCD needs ff_ctzll, an extension of ff_ctz for long long (int64_t). On
GCC, this is provided by a built-in. On Microsoft, there is a
BitScanForward64 analog of BitScanForward that should work; but I can't confirm.
Apparently it is not available on 32 bit builds; so this may or may not
work correctly. On Intel, per the documentation there is only an
intrinsic for _bit_scan_forward and people have posted on forums
regarding _bit_scan_forward64, but often their documentation is
woeful. Again, I don't have it, so I can't test.
As such, to be safe, for now only the GCC/Clang intrinsic is added, the rest
use a compiled version based on the De-Bruijn method of Leiserson et al:
http://supertech.csail.mit.edu/papers/debruijn.pdf.
Tested with FATE, sample benchmark (x86-64, GCC 5.2.0, Haswell)
with a START_TIMER and STOP_TIMER in libavutil/rationsl.c, followed by a
make fate.
aac-am00_88.err:
builtin:
714 decicycles in av_gcd, 4095 runs, 1 skips
de-bruijn:
1440 decicycles in av_gcd, 4096 runs, 0 skips
previous:
2889 decicycles in av_gcd, 4096 runs, 0 skips
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
doc/resampler, swresample/options: use proper capitalization
Proper names should be capitalized in all user facing API as far as
possible. The option names themselves have not been changed since:
1. We consistently keep option names in lower case.
2. Changing them would break existing scripts.
3. I suspect that we want to be similar to Sox and its relevant options.
The converse is also true: improper names should not be capitalized
generally.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
During a build, a lot of *.o.-hash files are created - had not noticed
this as they are usually dumped in tmpfs on Linux. However, they
sometimes are present during a long build in the project directory, making it
annoying to commit while the project is being built.
These have been observed with Clang, -fsanitize-undefined on Arch Linux,
though other configurations may also generate such temporaries.
The solution here is on lines with the Linux kernel's .gitignore:
https://github.com/torvalds/linux/blob/master/.gitignore.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
doc/scaler, swscale/options: use proper capitalization
Proper names should be capitalized in all user facing API as far as
possible. The option names themselves have not been changed since:
1. We consistently keep option names in lower case.
2. Changing them would break existing scripts.
The converse is also true: improper names should not be capitalized
generally.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This should fix the undefined behavior reported in:
https://trac.ffmpeg.org/ticket/4727.
I can reproduce this at runtime: simply stick in an abort call in
asym_quant to check if c < 0 and run FATE. I don't know ac3 so I can't
confirm if negative coefficients are intentional, but at the moment they
clearly are according to FATE.
This resolves the undefined behavior. Tested with FATE.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
赵宇龙 [Fri, 9 Oct 2015 05:59:56 +0000 (13:59 +0800)]
h264_mp4toannexb: fix the pps offset when there are more than one sps in avcc
the pps offset is used to locate pps in the spspps_buf; however, the
current calc method is wrong because it is the offset of the original
avctx->extradata;
when there is only one sps in the avcc; the value is correct by
coincidence, however, it will fail in avcc with multi sps
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This fixes a warning observed on Clang 3.7:
"warning: attribute 'deprecated' is ignored, place it after "struct" to apply attribute to type declaration [-Wignored-attributes]"
and thus enables deprecation warning for the relevant struct.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com> Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Currently only 2 profiles are evaluated because they are the only 2
with distributed test sequences.
- CID 1260: YUV 4:2:2 10 bits with block-adaptive interlace coding,
from ticket 4876;
- CID 1270: YUV 4:4:4 10 bits (HR), 1920x839, from ticket 4581.
They were generated from the ticket sequences by running the
following kind of command-line;
ffmpeg -i $INPUT -an -sn -vcodec copy -vframes 1 -y $OUTPUT.mov
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
On lines 1633,1634 FFABS(pts) is performed. However, if av_stream_get_end_pts
returns AV_NOPTS_VALUE always, pts remains stuck at INT64_MIN, leading
to undefined behavior on FFABS.
One could conceive of a solution using FFNABS. However, such a solution
has to deal with the implementation defined rounding of integer division
with at least one negative operand in ANSI C89. C99 forces truncation to
zero, but I am not sure that all of our platforms compile with full C99
support, and in particular whether we can safely assume a fixed
rounding behavior across all platforms.
This solution is simple, and I doubt changing INT64_MIN to INT64_MIN + 1
has any practical loss - if it is stuck at its initial value, the stream
is messed up anyway.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When trying to build the binary dct-test under MSYS2/Win64, the
makefile rule does not have the SUBDIR in the target for its
object file.
Consequently, modifications to various include files (e.g. C ones)
do not trigger a recompilation.
When tracing the dependency generating, the dependency generation
has this strange content (linebreak inserted):
sed -e "/^#.*/d" -e "s,^[[:space:]]*dct\\.o,libavcodec/dct.o," \
> libavcodec/dct-test.d
For some reason, the $(*F) has weird content. It looks simpler to
use $(@F) instead of $(*F)\\.o, although this was tested on one
single version of make.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Jean Delvare [Wed, 7 Oct 2015 13:03:32 +0000 (15:03 +0200)]
avfilter/delogo: Set default band to 1
The original interpolation algorithm behaved poorly on the borders and
did not even guarantee continuity at the borders. For this reason, a
second interpolation/blending pass was required on the borders to make
them seamless.
However, since the interpolation algorithm was improved in June 2013,
the border issues no longer exist. The new algorithm does guarantee
continuity at the borders, making the second pass useless. A larger
band always increases the cumulated interpolation error. In most cases
it also increases the average interpolation error, even though the
samples in the band are only partially interpolated.
For this reason I would like to get rid of the "band" parameter. As a
first step, let's change its default value from 4 to 1 and document it
as deprecated.
I have benchmarked this change on a combination of input sources and
realistic logo areas. Lowering the band value from 4 to 1 resulted in
8 to 39 % less interpolation error per frame (or 1 to 34 % less
interpolation error per luma sample.)
Signed-off-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Stefano Sabatini <stefasab@gmail.com>
The MBAFF handling recently introduced on the decoder side shows that
the encoder does not support it correctly. Therefore, make the related
profile experimental.
Furthermore, current encoder logic treats it as unable to encode as
progressive, which isn't the case.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Profiles 1256 & 1270 (currently) signal at the frame header and MB
levels the colorspace used, either RGB or YUV. While a MB-level
varying colorspace is not supported, whether it is constant can be
tracked so as to determine the exact colorspace.
This requires having bitdepth and the ACT and 4:4:4 flags, in turn
needing the CID. Because setting those before having validated
enough things may result in invalid/unset DSP fucntions, setting
the bitdepth in the context is delayed.
It is not tested against a true RGB sequence, though.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Luca Barbato [Mon, 5 Oct 2015 01:41:41 +0000 (03:41 +0200)]
configure: When disabling a library disable all the related components
This way is sufficient to use the component specific configure variable
and not guard against the global library configure variable in code
that is outside it (e.g. checkasm).
place primary audio coding header data into DCAAudioHeader
structure to make DCAContext clearer
and move channel related data to DCAChan structure to make
them easier to use by extensions
The -threads option is ignored with libkvazaar since it does not have
any of the AV_CODEC_CAP_{FRAME,SLICE,AUTO}_THREADS capabilities. This
commit removes the incorrect documentation as well as the no-op of
setting the number of threads in libkvazaar encoder.
Changes function libkvazaar_encode to return proper error codes instead
of crashing when the video dimensions or pixel format change in the
middle of encoding.
libkvazaar: Update to work with the latest version
Function encoder_encode in Kvazaar API was changed to have new output
parameters: source picture and frame info. Frame info is used to set the
keyframe flag and source picture is ignored.