Roll FFMpeg for M22.

Roll FFMpeg for M22.

Notable new features:
- pcm_s16be, pcm_s24be support for chromium. gsm for chromeos.
- preroll stripping for mp3 files encoded with LAME or FFmpeg.

Includes the usual cadre of bug fixes and enhancements.  Fixes a
known crash on ARM per fischman.

BUG=none
TEST=manual, unit tests + asan, tsan, valgrind, etc.

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=148968

[DaleCurtis, 2012-07-27 22:46:56]

Vlad's almost finished his manual pass.

[scherkus (not reviewing), 2012-07-28 21:31:58]

just a few q's

http://codereview.chromium.org/10828038/diff/5/media/ffmpeg/ffmpeg_regression...
File media/ffmpeg/ffmpeg_regression_tests.cc (right):

http://codereview.chromium.org/10828038/diff/5/media/ffmpeg/ffmpeg_regression...
media/ffmpeg/ffmpeg_regression_tests.cc:146:
"abc9702fc46f49d6f26da5c62d118cf7");
what's going on with these two?

http://codereview.chromium.org/10828038/diff/5/media/ffmpeg/ffmpeg_regression...
media/ffmpeg/ffmpeg_regression_tests.cc:313: FLAKY_FFMPEG_TEST_CASE(MP4_10,
"security/null1.m4a");
do we know why?

[DaleCurtis, 2012-07-28 22:02:21]

http://codereview.chromium.org/10828038/diff/5/media/ffmpeg/ffmpeg_regression...
File media/ffmpeg/ffmpeg_regression_tests.cc (right):

http://codereview.chromium.org/10828038/diff/5/media/ffmpeg/ffmpeg_regression...
media/ffmpeg/ffmpeg_regression_tests.cc:146:
"abc9702fc46f49d6f26da5c62d118cf7");
On 2012/07/28 21:31:58, scherkus wrote:
> what's going on with these two?

My guess is upstream tightened decoder compliance. These are both invalid files
and have never played well, now they throws an explicit error which is good.

Per rbultje decoded output isn't guaranteed under error, so the hashes are
really just to help me track what's changing in the event we _don't_ get an
error code.

http://codereview.chromium.org/10828038/diff/5/media/ffmpeg/ffmpeg_regression...
media/ffmpeg/ffmpeg_regression_tests.cc:313: FLAKY_FFMPEG_TEST_CASE(MP4_10,
"security/null1.m4a");
On 2012/07/28 21:31:58, scherkus wrote:
> do we know why?

The test fails because after seek to zero we get a PIPELINE_ERROR_DECODE and the
test doesn't have a way to specify an after seek status that's different from
the initial status; which is required to be PIPELINE_OK to run the seek test.

I haven't looked closely beyond making sure loop worked with a valid m4a file. 
It's not a valid file, so the fact that it fails isn't surprising.  I'll take a
closer look on Monday.

Again though, this file has never played well and is not valid, so getting an
error is good.  What would be better is getting the error before the seek
though!

[scherkus (not reviewing), 2012-07-28 22:39:26]

lgtm