avformat/tcp: workaround for IOS9 getaddrinfo in IPv6 only network use hardcode IPv4 address can not resolve port number.
Signed-off-by: liujingchao <jcliu@outlook.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

When ffplay is used to play from the RTSP URL that serves 24 bit audio
content, ffplay fails to recognize the audio codec format. The attached
patch adds support for playing 24 bit audio content over RTSP by
defining a dynamic payload handler for "L24".
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

This includes the absolute path

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

This test tests some odd sample with odd aspect ratio
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Matt Oliver <protogonoi@gmail.com>

Signed-off-by: Matt Oliver <protogonoi@gmail.com>

Signed-off-by: Matt Oliver <protogonoi@gmail.com>

Signed-off-by: Matt Oliver <protogonoi@gmail.com>

Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>

Fixes valgrind warnings about usage of uninitialized values.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>

Tested-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>

The bitstream filters do not work with merged in side data

This leaves the input packet split if it is being split.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>

This reverts commit fba2a8a2.

The changes were right for av_write_frame() but not for av_interleaved_write_frame().
The following commit will fix this in a simpler way.
Signed-off-by: James Almer <jamrial@gmail.com>

This was fixed in 9a277808

doc/examples: add fuzz target for individual ffmpeg APIs for in-process fuzzing with libFuzzer, AFL, and similar fuzzing engines.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Similarly, merge it back before returning.

Fixes ticket #5927.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>

If it fails, buffers aren't allocated, causing NULL pointer dereferencing.
Reviewed-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

Otherwise it can be non-zero next time decode_lowdelay is called, causing
slice_params_buf not to be allocated, leading to a NULL pointer dereference.

The problem was introduced in commit
dcad4677.
Reviewed-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

This fixes a double-free detected by AddressSanitizer.

The problem was introduced in commit
dcad4677.
Reviewed-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

"Vidvox Hap", not "Vidvox Hap encoder" or "Vidvox Hap decoder". Fixes
bad name in "ffmpeg -codecs", matches other codec naming.
Signed-off-by: Paul B Mahol <onemda@gmail.com>

It should only be done for DEVICE_BUSY/IN_EXECUTION

(cherry picked from commit 0956fd46)
Fixes ticket #5924.

Fixes ticket #5193.

2-channels convolution using complex fft
improves speed significantly

not sure if it should be enabled by default
so disable it by default
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>

This is in the same the same vein as c981b114.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

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

this is somewhat a magic number, which can be understood from reading section
"7.1.2 Exponent Strategy" of the ac3 specification, in short:
Three exponents each represented as number 0-4 are grouped together and
base-5 encoded, so the maximal correct value is 25*4 + 5*4 + 4 = 124.
Reviewed-by: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

The framework will allocate a buffer and copy the data to it,
that takes time. But it avoids constently creating and
destroyng the shared memory segment, and that saves more time.

On my setup,
from ~200 to ~300 FPS at full screen (1920×1200),
from ~1400 to ~3300 at smaller size (640×480),
similar to legacy x11grab and confirmed by others.

Plus, shared memory segments are a scarce resource,
allocating potentially many is a bad idea.

Note: if the application were to drop all references to the
buffer before the next call to av_read_frame(), then passing
the shared memory segment as a refcounted buffer would be
even more efficient, but it is hard to guarantee, and it does
not happen with the ffmpeg command-line tool. Using a small
number of preallocated buffers and resorting to a copy when
the pool is exhausted would be a solution to get the better
of both worlds.

According to spec ISO_IEC_15444_12 "For any media stream for which no segment index is present, referred to as non‐indexed stream, the media stream associated with the first Segment Index box in the segment serves as a reference stream in a sense that it also describes the subsegments for any non‐indexed media stream."
Signed-off-by: Sasi Inguva <isasi@google.com>
Reviewed-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Avoids a forward-declaration in the following commit.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

* commit '722ec3eb':
  avconv: decouple configuring filtergraphs and setting input parameters
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

This was broken by the following Libav commit:
4c387c70 ppc: dsputil: do unaligned block accesses correctly

The following tests fail due to this:
fate-checkasm
fate-vsynth1-dnxhd-2k-hr-hq fate-vsynth1-dnxhd-edge1-hr
fate-vsynth1-dnxhd-edge2-hr fate-vsynth1-dnxhd-edge3-hr
fate-vsynth1-dnxhd-hr-sq-mov fate-vsynth1-dnxhd-hr-hq-mov
fate-vsynth2-dnxhd-2k-hr-hq fate-vsynth2-dnxhd-edge1-hr
fate-vsynth2-dnxhd-edge2-hr fate-vsynth2-dnxhd-edge3-hr
fate-vsynth2-dnxhd-hr-sq-mov fate-vsynth2-dnxhd-hr-hq-mov
fate-vsynth3-dnxhd-2k-hr-hq fate-vsynth3-dnxhd-edge1-hr
fate-vsynth3-dnxhd-edge2-hr fate-vsynth3-dnxhd-edge3-hr
fate-vsynth3-dnxhd-hr-sq-mov fate-vsynth3-dnxhd-hr-hq-mov

Fixes trac ticket #5508.
Reviewed-by: Carl Eugen Hoyos <ceffmpeg@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

The parser depends on the codec and thus must not be used with a different one.
If it is, the 'avctx->codec_id == s->parser->codec_ids[0] ...' assert in
av_parser_parse2 gets triggered.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

We don't need to document the horrible hacks that we removed.

The old code had to retain a partial frame across two calls in
the case of separate interlaced fields. Now, we know that we'll
get both fields within the same receive_frame call, and so we
don't need to manage the frame as private state any more.

It's not possible to return EAGAIN when we've passed input EOF and are
in draining mode. If do return EAGAIN, we're saying there's no way to
get any more output - which isn't true in many cases.

So let's handled these cases in an internal loop as best we can.

Now that we don't need to do ridiculous things to work out if a
frame is interlaced or not, we don't need an extra h.264 parser.

This was needed to detect an interlaced failure case that doesn't
happen with the new decode api.