Clément Bœsch [Sun, 26 Mar 2017 18:51:14 +0000 (20:51 +0200)]
lavfi/xbr: undef PI if defined
This conflict with the DJGPP libc math.h which includes a PI macro (to
M_PI).
We cannot make DJGPP POSIX only (using -D_POSIX_SOURCE) to avoid this
kind of symbols conflicts due to the lack of both posix_memalign and
memalign (DJGPP non standard function) in that POSIX mode. We currently
rely on memalign for aligned heap allocation.
Clément Bœsch [Sun, 26 Mar 2017 18:43:11 +0000 (20:43 +0200)]
lavfi/psnr: rename pow2 to pow_2
This conflict with the DJGPP libc which includes a pow2 function¹
We cannot make DJGPP POSIX only (using -D_POSIX_SOURCE) to avoid this
kind of symbols conflicts due to the lack of both posix_memalign and
memalign (DJGPP non standard function) in that POSIX mode. We currently
rely on memalign for aligned heap allocation.
Clément Bœsch [Sun, 26 Mar 2017 18:41:41 +0000 (20:41 +0200)]
lavfi/dynaudnorm: rename pow2 to pow_2
This conflict with the DJGPP libc which includes a pow2 function¹
We cannot make DJGPP POSIX only (using -D_POSIX_SOURCE) to avoid this
kind of symbols conflicts due to the lack of both posix_memalign and
memalign (DJGPP non standard function) in that POSIX mode. We currently
rely on memalign for aligned heap allocation.
wm4 [Mon, 27 Mar 2017 12:25:53 +0000 (14:25 +0200)]
pthread_frame: minor simplification to error handling
Get rid of the "ret" variable, and always use err. Report the packet as
consumed if err is unset. This should be equivalent to the old code,
which obviously required err=0 for p->result>=0 (and otherwise,
p->result must have had the value err was last set to). The code block
added by commit 32a5b631267 is also not needed anymore, because the new
code strictly returns err if it's >=0.
Reviewed-by: "Ronald S. Bultje" <rsbultje@gmail.com>
Ronald S. Bultje [Tue, 28 Mar 2017 19:04:46 +0000 (15:04 -0400)]
pthread_frame: don't sync items between threads for intra-only codecs.
Intra-only codecs should either be able to read these items from the
bitstream, or they should be set upon codec initialization. In both
cases, syncing these items at runtime is unnecessary.
In practice, this fixes race conditions for decoders that read these
values from the bitstream.
Clément Bœsch [Tue, 28 Mar 2017 16:00:02 +0000 (18:00 +0200)]
lavfi: fix race when func rets holder is NULL
If ret is NULL, a dummy common holder is created to hold *all* the
parallel function returns, which gets written concurrently. This commit
simplify the whole logic by simply not writing to that holder when not
set.
adding demuxer and other logs should be easy
This forces single threaded decoding for simplicity
It also requires pthreads, this could be avoided either with
some lockless tricks or simply by assuming av_log would never be called from
another thread.
Fixes Ticket5521
Previous version reviewed by Stefano Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This commit is a noop, a different fix is included in the big -Wformat
patch under review
(http://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209239.html)
This commit is a noop, an equivalent patch is currently under review on
the mailing-list: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209239.html
wm4 [Mon, 27 Mar 2017 11:06:56 +0000 (13:06 +0200)]
pthread_frame: fix uninitialized variable read
Could lead to random behavior. This possibly happened due to commit 32a5b631267. This should/could probably be simplified, but for no apply
a minimal fix to quell the errors.
Tested-by: Michael Niedermayer <michael@niedermayer.cc> Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
wm4 [Thu, 23 Mar 2017 12:18:16 +0000 (13:18 +0100)]
pthread_frame: do not attempt to unlock a mutex on the wrong thread
async_mutex has is used in a very strange but intentional way: it is
locked by default, and unlocked only in regions that can be run
concurrently.
If the user was calling API functions to the same context from different
threads (in a safe way), this could unintentionally unlock the mutex on
a different thread than the previous lock operation. It's not allowed by
the pthread API.
Fix this by emulating a binary semaphore using a mutex and condition
variable. (Posix semaphores are not available on all platforms.)
Tested-by: Michael Niedermayer <michael@niedermayer.cc> Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
wm4 [Tue, 21 Mar 2017 07:02:58 +0000 (08:02 +0100)]
avformat, ffmpeg: deprecate old rotation API
The old "API" that signaled rotation as a metadata value has been
replaced by DISPLAYMATRIX side data quite a while ago.
There is no reason to make muxers/demuxers/API users support both. In
addition, the metadata API is dangerous, as user tags could "leak" into
it, creating unintended features or bugs.
ffmpeg CLI has to be updated to use the new API. In particular, we must
not allow to leak the "rotate" tag into the muxer. Some muxers will
catch this properly (like mov), but others (like mkv) can add it as
generic tag. Note applications, which use libavformat and assume the
old rotate API, will interpret such "rotate" user tags as rotate
metadata (which it is not), and incorrectly rotate the video.
The ffmpeg/ffplay tools drop the use of the old API for muxing and
demuxing, as all muxers/demuxers support the new API. This will mean
that the tools will not mistakenly interpret per-track "rotate" user
tags as rotate metadata. It will _not_ be treated as regression.
Unfortunately, hacks have been added, that allow the user to override
rotation by setting metadata explicitly, e.g. via
-metadata:s:v:0 rotate=0
See references to trac #4560. fate-filter-meta-4560-rotate0 tests this.
It's easier to adjust the hack for supporting it than arguing for its
removal, so ffmpeg CLI now explicitly catches this case, and essentially
replaces the "rotate" value with a display matrix side data. (It would
be easier for both user and implementation to create an explicit option
for rotation.)
When the code under FF_API_OLD_ROTATE_API is disabled, one FATE
reference file has to be updated (because "rotate" is not exported
anymore).
Tested-by: Michael Niedermayer <michael@niedermayer.cc> Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Kyle Swanson [Sun, 26 Mar 2017 18:48:28 +0000 (13:48 -0500)]
libavcodec/opusenc: use correct format specifiers
Squelches the following compiler warnings:
libavcodec/opusenc.c:1051:16: warning: format specifies type 'long' but
the argument has type 'long long' [-Wformat]
avctx->bit_rate/1000, clipped_rate/1000);
^~~~~~~~~~~~~~~~~~~~
libavcodec/opusenc.c:1051:38: warning: format specifies type 'long' but
the argument has type 'long long' [-Wformat]
avctx->bit_rate/1000, clipped_rate/1000);
^~~~~~~~~~~~~~~~~
projects / ffmpeg / log