* commit '1077d8c8455b27688de37cd04f8cc253fb37944d':
configure: Add -framework CoreVideo when building the avfoundation indev
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'bf12a81cc67d62dd45c58e29fa0e9177331cc151':
configure: Replace `pr` since it is not provided by busybox
Not merged as requested by Timothy Gu.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '5f3a081b42b84404a40a52c80ef7a354cf048c56':
avi: Spin out the logic to position to the next non-interleaved stream
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
Don't print a warning when dcadec_context_filter() returns positive
warning code. Most relevant warnings are now output through the callback
function.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Take request_channel_layout as a hint and don't force 2.0 downmix by
using both the 2CH and 6CH flags together.
Remove warnings about missing coefficients because they are no longer
relevant.
Honor AV_CH_LAYOUT_NATIVE and make it possible for native DTS channel
layout to be output.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
matroskaenc applies divisors to the display width/height when generating
stereo content. This patch adds the corresponding multipliers to matroskadec
so that the original sample aspect ratio can be recovered.
Signed-off-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
These variables are coming from mpegvideoenc where are supposedly used
as bit counters on various frame properties. However their use is
unclear as they lack documentation, are available only from a very small
subset of encoders, and they are hardly used in the wild. Also frame_bits
in aacenc is employed in a similar way.
Remove this functionality from AVCodecContex, these variable are mostly
frame properties, and too few encoders support setting them with anything
useful.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Most option values are simply unused or ignored and in practice the
majory of codecs only need to check whether to enable rle or not.
Add appropriate codec private options which better expose the allowed
features.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
* commit 'f023d57d355ff3b917f1aad9b03db5c293ec4244':
lavc: G.723.1 encoder
Split existing FFmpeg G.723.1 encoder into a new file.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '165cc6fb9defcd79fd71c08167f3e8df26b058ff':
g723_1: Move sharable functions to a separate file
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'aac996cc01042194bf621d845bbe684549b5882e':
g723_1: Rename files to better reflect their purpose
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'b74b88f30da2389f333a31815d8326d5576d3331':
g723_1: Handle values at the ends of the table in lsp2lpc()
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'a0fa6d06b848f26b16ba12f0a9a4a85b93ab8022':
matroska: Warn when metadata references a non-existent element
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit '4f979418c723652ad4e43115118c57a44bd46b52':
avfoundation: Simple capture
Not merged on request by Thilo Borgmann, original author of the
AVFoundation capture in FFmpeg.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
Fix a dead lock under certain conditions. Let's assume we have a queue of 1
message max, 2 senders, and 1 receiver.
Scenario (real record obtained with debug added):
[...]
SENDER #0: acquired lock
SENDER #0: queue is full, wait
SENDER #1: acquired lock
SENDER #1: queue is full, wait
RECEIVER: acquired lock
RECEIVER: reading a msg from the queue
RECEIVER: signal the cond
RECEIVER: acquired lock
RECEIVER: queue is empty, wait
SENDER #0: writing a msg the queue
SENDER #0: signal the cond
SENDER #0: acquired lock
SENDER #0: queue is full, wait
SENDER #1: queue is full, wait
Translated:
- initially the queue contains 1/1 message with 2 senders blocking on
it, waiting to push another message.
- Meanwhile the receiver is obtaining the lock, read the message,
signal & release the lock. For some reason it is able to acquire the
lock again before the signal wakes up one of the sender. Since it
just emptied the queue, the reader waits for the queue to fill up
again.
- The signal finally reaches one of the sender, which writes a message
and then signal the condition. Unfortunately, instead of waking up
the reader, it actually wakes up the other worker (signal = notify
the condition just for 1 waiter), who can't push another message in
the queue because it's full.
- Meanwhile, the receiver is still waiting. Deadlock.
This scenario can be triggered with for example:
tests/api/api-threadmessage-test 1 2 100 100 1 1000 1000
One working solution is to make av_thread_message_queue_{send,recv}()
call pthread_cond_broadcast() instead of pthread_cond_signal() so both
senders and receivers are unlocked when work is done (be it reading or
writing).
This second solution replaces the condition with two: one to notify the
senders, and one to notify the receivers. This prevents senders from
notifying other senders instead of a reader, and the other way around.
It also avoid broadcasting to everyone like the first solution, and is,
as a result in theory more optimized.
