The previous implementation targeted DTS Coherent Acoustics, which only
requires mdct_bits == 6. This relatively small size lent itself to
unrolling the loops a small number of times, and encoding offsets
calculated at assembly time within the load/store instructions of each
iteration.

In the more general case (codecs such as AAC and AC3) much larger arrays
are used - mdct_bits == [8, 9, 11]. The old method does not scale for
these cases, so more integer registers are used with non-unrolled versions
of the loops (and with some stack spillage). The postrotation filter loop
is still unrolled by a factor of 2 to permit the double-buffering of some
VFP registers to facilitate overlap of neighbouring iterations.

I benchmarked the result by measuring the number of gperftools samples
that hit anywhere in the AAC decoder (starting from aac_decode_frame())
or specifically in ff_imdct_half_c / ff_imdct_half_vfp, for the same
example AAC stream:

                  Before          After
                  Mean   StdDev   Mean   StdDev  Confidence  Change
aac_decode_frame  2368.1 35.8     2117.2 35.3    100.0%      +11.8%
ff_imdct_half_*   457.5  22.4     251.2  16.2    100.0%      +82.1%
Signed-off-by: Martin Storsjö <martin@martin.st>

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

This makes the init files match the structure of the dsputil split.

Signed-off-by: Diego Biurrun <diego@biurrun.de>

Signed-off-by: Diego Biurrun <diego@biurrun.de>
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

This fixes running fate in configs where the samples are located
in a different path on the target.
Signed-off-by: Martin Storsjö <martin@martin.st>

The remaining dsputil bits are encoding-specific anyway.

doc/examples/output.c:460:9: warning: unused variable ‘i’

The specification requires at most 1 track enabled per alternate group.

Sample-Id: OPFLAG_B_Qualcomm_1.bit, OPFLAG_C_Qualcomm_1.bit
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Diego Biurrun <diego@biurrun.de>

AVFormatContext->priv_data is not always a MpegTSContext, it can be
RTSPState when decoding a RTP stream. So it is necessary to pass
MpegTSContext pointer explicitly.

Within libav, the write_section_data function doesn't actually use
the MpegTSContext at all, so this doesn't change anything at the
moment (no memory was corrupted before), but it reduces the risk of
anybody trying to touch the MpegTSContext via AVFormatContext->priv_data
in the future.
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Use it for logging, instead of NULL or the stream codec context.

Its contents are meaningful only if the stream codec context is the one
actually used for encoding, which is often not the case (and is
discouraged).

Use AVCodecContext.field_order instead.

It is supposed to be set by decoders only.

The only thing the demuxer needs is the sample rate to set the timebase,
which can be simply read with AV_RB32.

This is required by the new API.

The callers should now set the stream timebase, not the codec one.

Bug-Id: 55

This silences a warning with gcc.
Signed-off-by: Martin Storsjö <martin@martin.st>

This was broken (left half-implemented) in 354468fc.

CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>