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>

11% faster on penryn, 7% on sandybridge, 5% on bulldozer
Negligible change to output.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

14% faster on penryn, 2% on sandybridge, 9% on bulldozer
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

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

Change code style to match the rest of libav.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

This allows us to unconditionally set the cglobal num_args
parameter to a bigger value, thus making writing yasm code
even easier than before.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

Without this, cglobal will expand "z" to "zh" to access the high byte
in a register's word, which causes a name collision with the ZH(x) macro
further up in this file.

Don't invent a bogus EIO error.

The code now doesn't check for ret == 0, but that check is redundant,
av_get_packet() never returns 0.

Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Kostya Shishkov <kostya.shishkov@gmail.com>

Fixes overread

Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Kostya Shishkov <kostya.shishkov@gmail.com>

This fixes out of array writes

Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Kostya Shishkov <kostya.shishkov@gmail.com>

Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Kostya Shishkov <kostya.shishkov@gmail.com>

64-bit CPUs always have SSE2, and a SSE2 version exists, thus the MMX
version will never be used.

This allows non-standard replacements for the -c compiler flag.
Some compilers use other flags or no flag at all in place of
the usual one.
Signed-off-by: Mans Rullgard <mans@mansr.com>