ffmpeg configured with webm decode only to avoid postproc that pulls in unuse...

ffmpeg configured with webm decode only to avoid postproc that pulls in unused data
BUG=50507, 50533
TEST=xp perf should pass


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

[fbarchard, 2010-07-28 22:21:59]

XP perf was catching a bug in libvpx
The bug relates to encoding and post processing, so the work around is to create
a decode only library.
That requires a patch to ffmpeg to allow a decode only configuration
new binaries to follow.
Also the patches are all regenerated and marked as LF to address a patch fuzz
bug reported by fta.  They should all apply cleanly.
TBR=scherkus

[scherkus (not reviewing), 2010-07-28 22:45:37]

does this depend on checking in new libvpx libs?

http://codereview.chromium.org/3066011/diff/3001/4001
File README.chromium (right):

http://codereview.chromium.org/3066011/diff/3001/4001#newcode131
README.chromium:131: rm -rf orig
we don't have to do this now, but perhaps we can provide a shell script that
accomplishes this?

there's a lot of duplicated commands here that could be remedied with a bash
function :)

[fbarchard, 2010-07-28 23:01:15]

On 2010/07/28 22:45:37, scherkus wrote:
> does this depend on checking in new libvpx libs?

no new source, just reconfigured to --enable-vp8-decoder

> 
> http://codereview.chromium.org/3066011/diff/3001/4001
> File README.chromium (right):
> 
> http://codereview.chromium.org/3066011/diff/3001/4001#newcode131
> README.chromium:131: rm -rf orig
> we don't have to do this now, but perhaps we can provide a shell script that
> accomplishes this?
> 
> there's a lot of duplicated commands here that could be remedied with a bash
> function :)

I used to have one, but once it ran amok and killed patches, so I dont trust it.
 And its useful, when working on updates to a specific patch, to do all the
patches up to the interesting one, and then apply just the steps for that one
patch.
I could move it out of the readme, but it has to stay in lock step with the
patches.
Also I'm finding the step is useful... we have clean patches, that stay closer
to HEAD ffmpeg so they don't break as often.

[scherkus (not reviewing), 2010-07-28 23:06:54]

LGTM

[fgalligan, 2010-07-29 06:58:15]

The CL for removing the 1.6 MB global has been landed in libvpx
https://review.webmproject.org/#change,360



On Wed, Jul 28, 2010 at 7:01 PM, <fbarchard@chromium.org> wrote:

> On 2010/07/28 22:45:37, scherkus wrote:
>
>> does this depend on checking in new libvpx libs?
>>
>
> no new source, just reconfigured to --enable-vp8-decoder
>
>
>
>  http://codereview.chromium.org/3066011/diff/3001/4001
>> File README.chromium (right):
>>
>
>  http://codereview.chromium.org/3066011/diff/3001/4001#newcode131
>> README.chromium:131: rm -rf orig
>> we don't have to do this now, but perhaps we can provide a shell script
>> that
>> accomplishes this?
>>
>
>  there's a lot of duplicated commands here that could be remedied with a
>> bash
>> function :)
>>
>
> I used to have one, but once it ran amok and killed patches, so I dont
> trust it.
>  And its useful, when working on updates to a specific patch, to do all the
> patches up to the interesting one, and then apply just the steps for that
> one
> patch.
> I could move it out of the readme, but it has to stay in lock step with the
> patches.
> Also I'm finding the step is useful... we have clean patches, that stay
> closer
> to HEAD ffmpeg so they don't break as often.
>
>
>
> http://codereview.chromium.org/3066011/show
>