avutil: use EINVAL instead of -1 for the return code of crypto related init functions
These functions return an error typically when the key size is an
incorrect number. AVERROR(EINVAL) is more specific than -1.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com> Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Commit 3a0a2f33a6c955823fa4fb12c0b49cd29a496659 claims large performance
advantages for AV_QSORT over libc's qsort. The reason is that I suspect
that libc's qsort (at least on non LTO builds, like the typical FFmpeg config)
can't inline the comparison callback:
https://stackoverflow.com/questions/5290695/is-there-any-way-a-c-c-compiler-can-inline-a-c-callback-function.
AV_QSORT has two things going for it:
1. The guaranteed inlining of qsort itself. This yields a negligible
boost that may be ignored.
2. The more serious possibility of potentially allowing the comparison
function to be inlined - this is likely responsible for the large boosts
reported.
There is a comment explaining that this is a place that could use some
performance improvement. Thus AV_QSORT is used to achieve that.
Benchmarks deemed unnecessary due to existing claims about AV_QSORT.
Tested with FATE.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Alexis Ballier [Fri, 16 Oct 2015 08:42:33 +0000 (10:42 +0200)]
libavcodec/mpegvideo_enc.c: Fix encoding videos with less frames than the delay of the encoder.
When the encoder is fed with less frames than its delay, the picture list looks like { NULL, NULL, ..., frame, frame, frame }. When flushing the encoder (input frame == NULL), we need to ensure the picture list is shifted enough so that we do not return an empty packet, which would mean the encoder has finished, while it has not encoded any frame.
Before the patch, the command:
'./ffmpeg_g -loglevel debug -f lavfi -i "testsrc=d=0.01" -bf 2 -vcodec mpeg2video out.mxf' prints:
aacenc_ltp: adjust and speed up autocorrelation calculations
There were some errors in the calculation as well as an entire
unnecessary loop to find the gain coefficient. Merge the
two loops.
Thanks to @ubitux for the suggestions and testing.
av_warn_unused_result is added to functions whose return status should
be checked. Currently does not trigger any warnings, but should be
useful for future robustness.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
fate: use -profile:a aac_ltp instead of -aac_ltp 1 for LTP encode test
The fate test command line is supposed to serve as an example. It's
nicer to explicitly state the profile rather than setting options
to force it for you.
Changes:
- strongly prefer dual filters to a single filter
- less strict about using 2 filters w.r.t. energy
- scrap the usage of threshold and spread, useless
- use odd-shaped windows to set the filter direction
- use 4 bits instead of 3 bits for short windows
- simplify and reduce the main loop to a single level
- add stricter regulations for short windows
All of this now makes the TNS implementation operate
as good as it can and it definitely shows. The frequency
thresholds are now even better defined by looking at
the spectrals and the overall sound has been improved at
the price of just a few bits that are well worth it.
aacenc_tns: disable coefficient compression by default
Too much effort and work has been spent on such a simple function.
It simply refuses to work as the specifications say, the
transformation is NOT lossless and creates some crackling and
distortions.
Therefore disable it by default and add a couple of warnings to
scare people away from touching it or wasting their time the
way I did.
The decoder does this so I guess we better do that as well.
There's barely any difference between the autoregressive and
the moving average filters looking at spectrals though.
Timothy Gu [Mon, 12 Oct 2015 09:50:18 +0000 (02:50 -0700)]
opencl: Force the use of 1.2 APIs
Silences warnings regarding `clCreateCommandQueue` being deprecated.
Only a very limited number of products support 2.0. Since the
replacement API (`clCreateCommandQueueWithProperties`) is only available
in 2.0, we should not update it just yet.
GCC 3.4 miscompiles it on sunos. Date of release? The second of
August two thousand and five, anno Domini. That's ten years two
months and fourteen days ago. Three thousand seven hundred and
twenty seven days ago. One sixth of the average life expectancy
of a person living in a country with a human development index
of zero point eight hundred and eight, equality adjusted.
GCC 4.3 also miscompiles it, though not as bad.
fate: adjust aac encoder test values and introduce MS and LTP tests
The LTP encoding and the test is a bit slow currently, taking twice
the amount of time the other tests do, so in the future the
total time to encode might be cut down on that test.
aacenc: partially revert previous commits to set options via a profile
It didn't work out because of the exceptions that needed to be made
for the "-1" cases and was overall more confusing that just manually
checking and setting options for each profile.
aacenc: add support for encoding files using Long Term Prediction
Long Term Prediction allows for prediction of spectral coefficients
via the previously decoded time-dependent samples. This feature
works well with harmonic content 2 or more frames long, like speech,
human or non-human, piano music or any constant tones at very low
bitrates.
It should be noted that the current coder is highly efficient and
the rate control system is unable to encode files at extremely
low bitrates (less than 14kbps seems to be impossible) so this
extension isn't capable of optimum operation. Dramatic difference
is observable with some types of audio and speech but for the most
part the audiable differences are subtle. The spectrum looks better
however so the encoder is able to harvest the additional bits that
this feature provies, should the user choose to enable it. So
it's best to enable this feature only if encoding at the absolutely
lowest bitrate that the encoder is capable of.
Apparently it was set to be enabled by default but after the
profile commits it was reverted to be off by default because
I didn't notice.
Works well so (re)enable it.
Hendrik Leppkes [Wed, 14 Oct 2015 21:18:17 +0000 (23:18 +0200)]
w32pthreads: fix mingw build on x86 with -msse2 or higher
When SSE2 or higher compiler optimizations are used, mingw uses
the _mm_mfence intrinsic for MemoryBarrier, however it doesn't include
the appropriate headers automatically.
Hendrik Leppkes [Wed, 14 Oct 2015 21:20:09 +0000 (23:20 +0200)]
w32pthreads: fix mingw build on x86 with -msse2 or higher
When SSE2 or higher compiler optimizations are used, mingw uses
the _mm_mfence intrinsic for MemoryBarrier, however it doesn't include
the appropriate headers automatically.
projects / ffmpeg / log