Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Peter Ross <pross@xvid.org>

http://wiki.multimedia.cx/index.php?title=Electronic_Arts_SCxlReviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Such files have gaps between header chunks.
Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Register mmaldec as mpeg2 decoder. Supporting mpeg2 in mmaldec is just a
matter of setting the correct MMAL_ENCODING on the input port. To ease the
addition of further supported mmal codecs a macro is introduced to generate
the decoder and decoder class structs.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: wm4 <nfxjfg@googlemail.com>

Signed-off-by: James Almer <jamrial@gmail.com>

Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Marton Balint <cus@passwd.hu>

Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Marton Balint <cus@passwd.hu>

Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Marton Balint <cus@passwd.hu>

Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Marton Balint <cus@passwd.hu>

This function is only used within other inline asm functions, hence the
HAVE_MMX_INLINE guard. Per recent discussions, we should not worry about
the performance of inline asm-only builds.

libavformat/mxfdec.c: Report dark metadata keys only when they match no parser at all, not everytime they fail to match one.
Reviewed-by: Tomas Härdin <tomas.hardin@codemill.se>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Reviewed-by: Tomas Härdin <tomas.hardin@codemill.se>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

It is only used inside libavcodec.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

avpriv_ac3_parse_header was removed in commit 3dfb643c.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Oops.

SSE2 version 4%-35% faster than MMX depending on the width.
AVX2 version 1%-13% faster than SSE2 depending on the width.

There is no avpriv_atomic_get, instead avpriv_atomic_int_get is to be used for
integers. This fixes building mmaldec.
Signed-off-by: Julian Scheel <julian@jusst.de>
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Function protoypes without arguments require a void argument in C,
instead of an empty list.

This commit introduces a parser for the current bitstream produced by
Daala. It currently bears a large similarity with Theora, another
codec produced by Xiph. While likely to change in the future, its basic
format of packet parsing should remain fairly identical with its current
structure.
Once the bitstream freezes, there are a few probable simplifications
that could be made. Also, the current version (major, minor and micro)
is stuck at zero so it's unusable as a way to warn about possible
incompatibilities. This will change once the bitstream freezes,
however until then this file is strictly targeting the current git
master of the reference encoder, libdaala.

This file was developed independently at the same time by both myself
and Vittorio Giovara, who used libav as a starting point. For fairness,
and to prevent confusion and allegations, his name has been added to the
copyright in the license header as well, and vice versa.

This commit shall introduce the first step of adding support for the
Daala next generation video codec to FFmpeg. Although still in
development, the codec is showing good progress and exchanging work
through IETF drafts. The companies behind Daala are also participating
in the Alliance for Open Media, so it's likely that whatever the result
any of these collaborations produce it's probable that elements from
Daala could be used in them, or perhaps this codec itself could be the
result.

VP8E_UPD_ENTROPY, VP8E_UPD_REFERENCE, VP8E_USE_REFERENCE were removed
from libvpx and the remaining values were never used here
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Zern <jzern@google.com>

Heavily based upon ff_add_bytes by Christophe Gisquet.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Timothy Gu <timothygu99@gmail.com>

Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Also replace the last two usages of avpriv_float_dsp_init with
avpriv_float_dsp_alloc.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

It was replaced by avpriv_ac3_parse_header2.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

These headers contain functions supposed to be public.

libavutil/des.h:
 av_des_alloc
 av_des_crypt
 av_des_init
 av_des_mac
libavutil/rc4.h:
 av_rc4_alloc
 av_rc4_crypt
 av_rc4_init
libavutil/tree.h
 av_tree_destroy
 av_tree_enumerate
 av_tree_find
 av_tree_insert
 av_tree_node_alloc
 av_tree_node_size
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

This reverts commit 628e6d01 and uses
a better fix.

Before:
4483 decicycles in get_pixels_8x4_sym,  131032 runs,     40 skips

After:
2569 decicycles in get_pixels_8x4_sym,  131054 runs,     18 skips

The parser only reads the dca core sample rate, which is limited to a
maximum of 48000 Hz, while X96 and HD extensions can increase the sample
rate up to 192000 Hz.

This change prevents the parser and decoder fighting over the sample rate,
potentially confusing user applications. This also fixes sample rate
display of >48000Hz files with ffmpeg/ffprobe when using libdcadec.

Fixes ticket #4397

Commit 2b3e9bbf caused problems for a
certain API user:

https://code.google.com/p/chromium/issues/detail?id=537725
https://code.google.com/p/chromium/issues/detail?id=542032

The problem seems rather arbitrary, because if there's junk, anything
can happen. In this case, the imperfect junk skipping just caused it to
read different junk, from what I can see.

We can improve the accuracy of junk detection by a lot by checking if 2
consecutive frames use the same configuration. While in theory it might
be completely fine for the 1st frame to have a different format than the
2nd frame, it's exceedingly unlikely, and I can't think of a legitimate
use-case.

This is approximately the same mpg123 does for junk skipping. The
set of compared header bits is the same as the libavcodec mp3 parser
uses for similar purposes.

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

This is how the other perl scripts in git call perl
Reviewed-by: Ganesh Ajjanagadde <gajjanag@mit.edu>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

It is done this way in huffyuvdsp as well.

That's where all yasm initiation steps are. Also removes the overlap
between the two files.

This function does not exist.