ffmpeg roll of source to mar 9 version...

ffmpeg roll of source to mar 9 version
improved vp3 threading
adds HE-AAC support
BUG=35850
TEST=should behave the same as before the roll


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=41388

[fbarchard, 2010-03-10 08:01:59]

In this ffmpeg roll (#4) there are 2 major areas we want
aac
ogg threading
minor changes elsewhere, but both aac and ogg should be considered a complete
refactor.
In a followup I will redo the patches to reduce 'fuzz'

[fbarchard, 2010-03-10 19:16:23]

The O2 part of the first patch is no longer necessary.  The parameter is passed
to the configure line for windows, and done by gyp for linux/mac.

deleted and added some stray files so the source matches the tarball process
exactly.

readme updated to new patch file names

[Alex Converse, 2010-03-10 20:57:31]

I added a bs_pointer bounds check after the initial commit.

http://codereview.chromium.org/789004/diff/26029/18026
File patched-ffmpeg-mt/libavcodec/aacsbr.c (right):

http://codereview.chromium.org/789004/diff/26029/18026#newcode672
patched-ffmpeg-mt/libavcodec/aacsbr.c:672: ch_data->bs_pointer = get_bits(gb,
ceil_log2[ch_data->bs_num_env[1]]);
bs_pointer going out of bounds can cause SEGFAULTs and other nastiness. See
r22380.

[fbarchard, 2010-03-10 21:45:30]

Thanks Alex.  I'll likely take that with the next ffmpeg-mt roll rather than an
additional patch

The immediate issue is the new ffmpeg isn't building?
There seems to be a compiler incompatibility.

I'm getting basic build issues on windows/msys using the standard ./configure &&
make

c:\msys\1.0\bin\../lib/gcc/mingw32/4.2.1-sjlj/../../../../include/inttypes.h:259
: error: no previous prototype for 'imaxabs'
In file included from ./libavutil/common.h:33,
                 from ./libavutil/avutil.h:71,
                 from ./libavcodec/avcodec.h:30,
                 from libavformat/avformat.h:56,
                 from ffprobe.c:24:
c:\msys\1.0\bin\../lib/gcc/mingw32/4.2.1-sjlj/../../../../include/math.h:357: er
ror: no previous prototype for '__fpclassifyl'

We use gcc-sjlj 4.2.
--cc=gcc-sjlj
gcc-sjlj.exe (GCC) 4.2.1-sjlj (mingw32-2)

If I switch to 4.4 it builds
This may be an option, if it works, for windows, since we check in binaries.
But on linux we still attempt to build with any gcc.  If the problem is
configuration, gyp wont care.

[Alex Converse, 2010-03-10 22:00:09]

On 2010/03/10 21:45:30, fbarchard wrote:
> But on linux we still attempt to build with any gcc.  If the problem is
> configuration, gyp wont care.

It is a configure change. It was to guard against functions slipping into
external linkage by mistake.

[fbarchard, 2010-03-12 03:57:50]

patching configure script allows new ffmpeg to build with gcc-sjlj
The newer gcc 4.4 compiles, but has a runtime issue.

TBR=cevans

[Lei Zhang, 2010-03-19 00:38:33]

http://codereview.chromium.org/789004/diff/60001/68018
File patched-ffmpeg-mt/libavcodec/mpeg4video_es_bsf.c (right):

http://codereview.chromium.org/789004/diff/60001/68018#newcode92
patched-ffmpeg-mt/libavcodec/mpeg4video_es_bsf.c:92: /*
Oh this is bad merge!