These functions are not faster than other mmx implementations on
any hardware I have been able to test on, and they are horribly
inaccurate.  There is thus no reason to ever use them.
Signed-off-by: Mans Rullgard <mans@mansr.com>

Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

At the moment it only does BGR24, but I plan to add the rest after.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

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

The standard syntax requires two destination registers for
LDRD/STRD instructions.  Some versions of the GNU assembler
allow using only one with the second implicit, others are
more strict.
Signed-off-by: Mans Rullgard <mans@mansr.com>

64-bit CPUs always have SSE available, thus there is no need to compile
in the 3dnow functions. This results in smaller binaries.

This will allow adding dca.c with tables used from other files.

They are managed in get_packet()
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

This fixes compilation with YASM disabled.

The yadif mmx optimizations contain the pmaxsw and pmaxub mmxext
instructions, causing sigills on CPUs that do not support mmxext.

This completes the conversion of h264dsp to yasm; note that h264 also
uses some dsputil functions, most notably qpel. Performance-wise, the
yasm-version is ~10 cycles faster (182->172) on x86-64, and ~8 cycles
faster (201->193) on x86-32.

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

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

These decoders use a special non-MPEG2 IDCT.  Call it directly
instead of going through dsputil.  There is never any reason
to use a regular IDCT with these decoders or to use the EA IDCT
with other codecs.

This also fixes the bizarre situation of eamad and eatqi decoding
incorrectly if eatgq is disabled.
Signed-off-by: Mans Rullgard <mans@mansr.com>

There is no sense in pulling in this monster struct just for
a handful of fields.  The code does not call any functions
expecting an MpegEncContext.
Signed-off-by: Mans Rullgard <mans@mansr.com>

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

This allows for padding/trimming at the start of stream. By default, no
assumption is made about the first frame's expected pts, so no padding or
trimming is done.

We match streams by codec id now.

According to its description, it is supposed to be the LCM of all the
frame durations. The usability of such a thing is vanishingly small,
especially since we cannot determine it with any amount of reliability.
Therefore get rid of it after the next bump.

Replace it with the average framerate where it makes sense.

FATE results for the wtv and xmv demux tests change. In the wtv case
this is caused by the file being corrupted (or possibly badly cut) and
containing invalid timestamps. This results in lavf estimating the
framerate wrong and making up wrong frame durations.
In the xmv case the file contains pts jumps, so again the estimated
framerate is far from anything sane and lavf again makes up different
frame durations.

In some other tests lavf starts making up frame durations from different
frame.

AVPacket.duration is mostly made up and thus completely useless, this is
especially true for video streams.
Therefore use dts difference for framerate estimation and
the max_analyze_duration check.

The asyncts test now needs -analyzeduration, because the default is 5
seconds and the audio stream in the sample appears at ~10 seconds.

Useful in cases where a significant analyzeduration is
still needed, while minimizing buffering before output.

An example is processing low-latency streams where all
media types won't necessarily come in if the
analyzeduration is small.

Additional changes by Josh Allmann <joshua.allmann@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>

MMX-enabled systems by default use some dsputil functions differing
from the C versions.  Adding these flags ensures accurate ones are
used everywhere.
Signed-off-by: Mans Rullgard <mans@mansr.com>

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