They are deprecated and will be purged on next major bump.

From the patch by Reimar Döffinger.

When decoding coefficients, detect whether the block is DC-only, and take
advantage of this knowledge to perform DC-only inverse transform.

This is achieved by:
- first, changing the 108x4 element modulo_three_table into a 108 element
  table (kind of base4), and accessing each value using mask and shifts.
- then, checking low bits for 0 (as they represent the presence of higher
  frequency coefficients)

Also provide x86 SIMD code for the DC-only inverse transform.
Signed-off-by: Kostya Shishkov <kostya.shishkov@gmail.com>

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

This is different than a normal get_bits() over read because
decode_audio_specific_config() creates its own GetBitContext.

Fixes Bug 170.

This is required to handle clobbering of XMM registers on Win64
correctly. Fixes FFT and all tests depending on FFT on Win64.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Janne Grunau <janne-libav@jannau.net>

This indicates that the actual frame size is based on the buf_size passed to
avcodec_encode_audio().

Since packets all contain only a single block, the generic seek function can
be used while still maintaining block-accuracy.

fixes stream copy of raw gsm to mov.
tested with QuickTime.

The WAVE demuxer returns packets with many blocks per frame, which needs to be
parsed into single blocks. This has a side-effect of fixing the timestamps.

Signed-off-by: Reinhard Tartler <siretart@tauware.de>

update documentation to inform developers that it may be removed in a
later release.
Signed-off-by: Reinhard Tartler <siretart@tauware.de>

Statistics for bourne.rmvb -an -f null

1 thread:  37.12s user 0.03s system  99% cpu 37.174 total
2 threads: 47.63s user 0.24s system 185% cpu 25.807 total
4 threads: 41.21s user 0.30s system 327% cpu 12.674 total

Under certain conditions pictures could be released before they were
returned with frame-threading. Broken mv computation in the upcoming
rv34 frame-threading patch was caused by this.

To prevent contexts from running out of available pictures the loop
releasing "unused" pictures has to be run for B frames too.

Fixes Libav Bug 195.

This doesn't make the code handle sample rate or upsample/downsample
change properly but this is still a good sanity check.

Based on change by Michael Niedermayer.
Signed-off-by: Alex Converse <alex.converse@gmail.com>

frame sample count calculation was incorrect

The duration of the first packet was being calculated incorrectly, leading to
an incorrect timestamp offset.

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

Additional comments from Måns Rullgard have been integrated
by Reinhard Tartler.
Signed-off-by: Reinhard Tartler <siretart@tauware.de>

Fixes a compilation failure on win64.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

It is not necessary to store the bit stream length in a RV34DecContext
field.

This is a hopefully temporary solution until lavfi can properly deal
with resolution changes.

This option only applies to streamcopy, but is currently processed only
when encoding.

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

If the creation time is stored in the file as a zero, the
mov demuxer skips exporting the creation time. Currently,
files muxed without a creation time get demuxed with a
Jan 1st 1970 creation timestamp.
Signed-off-by: Martin Storsjö <martin@martin.st>