Fixes Bug 203.

CC:libav-stable@libav.org

With all the VLAs gone, make sure they never come back.
Signed-off-by: Mans Rullgard <mans@mansr.com>

This gets rid of the variable-length scratch buffer by filtering 16
pixels at a time and writing directly to the destination.  The extra
loads this requires to load the source values are compensated by not
doing a round-trip to memory before shifting.
Signed-off-by: Mans Rullgard <mans@mansr.com>

Signed-off-by: Mans Rullgard <mans@mansr.com>

Instead of using an evil VLA, fall back to C version when edge
emulation is needed.  MPEG4 GMC is a rarely used fringe feature
so the speed loss is an acceptable cost for safer code.
Signed-off-by: Mans Rullgard <mans@mansr.com>

Signed-off-by: Martin Storsjö <martin@martin.st>

Discontinuous transmission is an addition to VAD/VBR operation, that
allows to greatly reduce bitrate for silent chunks or stationary
noises.
Signed-off-by: Martin Storsjö <martin@martin.st>

This is more consistent with what the rest of Libav does.

This breaks API.

It has been superseded by lavr.

The variable is copied to subsequent threads at the same time, so this
may cause wrong ref_count[] values to be copied to subsequent threads.

This bug was found using TSAN.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

ff_get_cpu_flags_x86() requires cpuid(), which is conditionally defined
elsewhere in the file.  Surrounding the function body with ifdefs allows
building even when cpuid is not defined.  An empty cpuflags mask is
returned in this case.

Now that there is CPU detection in YASM, there will always be one of
inline or external assembly enabled, which obviates the need to fall
back on CPU detection through compiler intrinsics.

This allows detecting CPU features with builds that have neither
gcc inline assembly nor the right compiler intrinsics enabled.

This works with gcc.  Other compilers might need to have a flag
mapping added.
Signed-off-by: Mans Rullgard <mans@mansr.com>

A new hidden config variable is added for the codecs that depend on the
mpegaudio parts.

Signed-off-by: Martin Storsjö <martin@martin.st>

This allows writing totally bare segments, without any header/trailer
included anywhere.
Signed-off-by: Martin Storsjö <martin@martin.st>

This makes sure any buffered data is written to the segment, for
muxers that buffer up data internally (e.g. fragmented mp4).
Signed-off-by: Martin Storsjö <martin@martin.st>

This makes sure new inline headers are emitted when the next
packet is written. This allows segmenting mpegts without calling
write_header/write_trailer (nor freeing/reiniting the muxer)
for each segment.
Signed-off-by: Martin Storsjö <martin@martin.st>

Some segmented formats (such as fragmented mp4) are "bare", as in,
the segment files do not have the same headers/trailers as full normal
files of that format have.
Signed-off-by: Martin Storsjö <martin@martin.st>

This makes sure the muxers are set up in the way they expect
with no data left around from the previous run (which could
cause various issues including memory leaks, depending on the chaine
muxer).

This fixes memory leaks with the mpegts and flv muxers. It also
makes the usage of chained muxers correct.
Signed-off-by: Martin Storsjö <martin@martin.st>

With this change, the segmenter muxer doesn't rely on anything
not available/supported to libavformat external users, making
the segmenter muxer do things just like a normal segmenter
application using libavformat would do.
Signed-off-by: Martin Storsjö <martin@martin.st>

Before, the chained muxer reused the AVStreams array from
the outer muxer, which made it impossible to use the proper
public functions (such as av_write_frame) when calling the
chained muxer.
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

Right now it incorrectly assumes that the frames are sent in the proper
order, which worked with old ffmpeg and avconv versions by accident.

Output frames correspond 1:1 to input frames on the main input.
So use the main input timebase for output.

Right now the buffer is zeroed, which does not represent silence for U8(P).

This will happen when the extradata is not a valid Speex header.

Signed-off-by: Martin Storsjö <martin@martin.st>

AVFrame.extended_data has to reset to the AVFrame.data of the current
thread context after copying the frame contents.
Fixes crashes with frame-threading after 2bc0de38.

When initialized as stereo, libspeex can decode either mono or stereo packets
and will output stereo.

If there is no extradata and the sample rate given by the user is not valid,
decode as ultra-wideband.