Fixup chromium specific bits after merge.

Fixup chromium specific bits after merge. Add binaries.
    
Completes the ffmpeg portion of the merge from upstream:
da1ba4e88b5bf723f8889798cb71f4e1cabb7a00
    
Adds all relevant config files and windows binaries. Another
CL will add the Windows internal bits.

Actual merge was too big for review, here is the diff after
patches plus my notes:

https://chromiumcodereview.appspot.com/9317107

The raw git repo can be found here:

http://git.chromium.org/gitweb/?p=chromium/third_party/ffmpeg.git;a=summary

TEST=unittests, layout tests, go/videotestmatrix.
BUG=110776

[DaleCurtis, 2012-02-04 03:43:53]

PTAL. Changes are 99% complete, need to rebuild Windows binaries one more time
after enabling get bits protections.

media code fixes are here: https://chromiumcodereview.appspot.com/9317096/

[Ami GONE FROM CHROMIUM, 2012-02-04 17:04:36]

I'll let scherkus review this, too :)

[ilja, 2012-02-06 06:55:55]

Looks good to me. I see that the windows config files changed slightly. This
seems to be due to a change that Andrew made in
http://codereview.chromium.org/8555017
Scanning through the bug I don't know if one has to check the binary property
again?

Nit: some years are updated and others are not.

[scherkus (not reviewing), 2012-02-06 17:57:54]

few q's

also with the binary name change there's a few scripts that package up
everything that will require updating (grep for avcodec-53, etc...)

https://chromiumcodereview.appspot.com/9325049/diff/3018/chromium/config/Chro...
File chromium/config/Chrome/mac/ia32/config.h (right):

https://chromiumcodereview.appspot.com/9325049/diff/3018/chromium/config/Chro...
chromium/config/Chrome/mac/ia32/config.h:253: #define
CONFIG_SAFE_BITSTREAM_READER 1
was this a result of cevans' original bitstream bounds-checking reader?

https://chromiumcodereview.appspot.com/9325049/diff/3018/chromium/config/Chro...
File chromium/config/Chrome/win/ia32/config.h (right):

https://chromiumcodereview.appspot.com/9325049/diff/3018/chromium/config/Chro...
chromium/config/Chrome/win/ia32/config.h:56: #define HAVE_W32THREADS 1
!!!

that static pthreads patch inside of configure should be irrelevant if ffmpeg
links directly to w32 threads

also: there's a bunch of crap and instructions under ./deps/third_party/mingw
and ./deps/third_party/pthreads-win32/ that can likely get deleted after we're
done

care to make an AI of this somewhere?

https://chromiumcodereview.appspot.com/9325049/diff/3018/chromium/scripts/bui...
File chromium/scripts/build_ffmpeg.sh (right):

https://chromiumcodereview.appspot.com/9325049/diff/3018/chromium/scripts/bui...
chromium/scripts/build_ffmpeg.sh:57: # If configure & make works but this script
doesn't, make sure to grep for these.
rietveld could be messing up on me but want to fix this line if its >80 chars?

https://chromiumcodereview.appspot.com/9325049/diff/3018/chromium/scripts/cop...
File chromium/scripts/copy_config.sh (right):

https://chromiumcodereview.appspot.com/9325049/diff/3018/chromium/scripts/cop...
chromium/scripts/copy_config.sh:13: for arch in arm arm-neon ia32 x64 ; do
nit: no space before ;

[DaleCurtis, 2012-02-06 19:35:03]

https://chromiumcodereview.appspot.com/9325049/diff/3018/chromium/config/Chro...
File chromium/config/Chrome/mac/ia32/config.h (right):

https://chromiumcodereview.appspot.com/9325049/diff/3018/chromium/config/Chro...
chromium/config/Chrome/mac/ia32/config.h:253: #define
CONFIG_SAFE_BITSTREAM_READER 1
On 2012/02/06 17:57:55, scherkus wrote:
> was this a result of cevans' original bitstream bounds-checking reader?

From what Ronald has told me, yes. Some of the security tests are still
generating crashes though, so I need to dig on this a bit more.

https://chromiumcodereview.appspot.com/9325049/diff/3018/chromium/config/Chro...
File chromium/config/Chrome/win/ia32/config.h (right):

https://chromiumcodereview.appspot.com/9325049/diff/3018/chromium/config/Chro...
chromium/config/Chrome/win/ia32/config.h:56: #define HAVE_W32THREADS 1
On 2012/02/06 17:57:55, scherkus wrote:
> !!!
> 
> that static pthreads patch inside of configure should be irrelevant if ffmpeg
> links directly to w32 threads
> 
> also: there's a bunch of crap and instructions under ./deps/third_party/mingw
> and ./deps/third_party/pthreads-win32/ that can likely get deleted after we're
> done
> 
> care to make an AI of this somewhere?

Awesome, I'll drop the patch and see what happens on Windows. Sure, I'll file an
issue for it.

https://chromiumcodereview.appspot.com/9325049/diff/3018/chromium/scripts/bui...
File chromium/scripts/build_ffmpeg.sh (right):

https://chromiumcodereview.appspot.com/9325049/diff/3018/chromium/scripts/bui...
chromium/scripts/build_ffmpeg.sh:57: # If configure & make works but this script
doesn't, make sure to grep for these.
On 2012/02/06 17:57:55, scherkus wrote:
> rietveld could be messing up on me but want to fix this line if its >80 chars?

Done.

https://chromiumcodereview.appspot.com/9325049/diff/3018/chromium/scripts/cop...
File chromium/scripts/copy_config.sh (right):

https://chromiumcodereview.appspot.com/9325049/diff/3018/chromium/scripts/cop...
chromium/scripts/copy_config.sh:13: for arch in arm arm-neon ia32 x64 ; do
On 2012/02/06 17:57:55, scherkus wrote:
> nit: no space before ;

Done.

[scherkus (not reviewing), 2012-02-06 19:38:48]

LGTM

[DaleCurtis, 2012-02-08 02:42:19]

I think we want to keep the static pthreads patch as it at least results in much
smaller (~30%) binaries. Otherwise I'm not sure what the difference is. As far
as I can tell HAVE_PTHREADS is set to 0 when W32THREADS is available, so
pthread.c uses w32pthreads instead of whatever is linked in.

Ronald, do you know more about this?

drwxr-xr-x 2 dalecurtis Administrators       0 Feb  7 18:04 .
drwxr-xr-x 9 dalecurtis Administrators    4096 Feb  7 18:03 ..
-rwxr-xr-x 1 dalecurtis Administrators 1367054 Feb  7 18:04 avcodec-54.dll
-rwxr-xr-x 1 dalecurtis Administrators  214030 Feb  7 18:04 avformat-54.dll
-rwxr-xr-x 1 dalecurtis Administrators  162830 Feb  7 18:03 avutil-51.dll

vs w/ static pthreads:

-rwxr-x--- 1 dalecurtis eng 982542 2012-02-07 17:35 avcodec-54.dll
-rwxr-x--- 1 dalecurtis eng 189454 2012-02-07 17:35 avformat-54.dll
-rwxr-x--- 1 dalecurtis eng 132622 2012-02-07 17:35 avutil-51.dll

[DaleCurtis, 2012-02-08 03:41:38]

On 2012/02/08 02:42:19, DaleCurtis wrote:
> I think we want to keep the static pthreads patch as it at least results in
much
> smaller (~30%) binaries. Otherwise I'm not sure what the difference is. As far
> as I can tell HAVE_PTHREADS is set to 0 when W32THREADS is available, so
> pthread.c uses w32pthreads instead of whatever is linked in.
> 
> Ronald, do you know more about this?
> 
> drwxr-xr-x 2 dalecurtis Administrators       0 Feb  7 18:04 .
> drwxr-xr-x 9 dalecurtis Administrators    4096 Feb  7 18:03 ..
> -rwxr-xr-x 1 dalecurtis Administrators 1367054 Feb  7 18:04 avcodec-54.dll
> -rwxr-xr-x 1 dalecurtis Administrators  214030 Feb  7 18:04 avformat-54.dll
> -rwxr-xr-x 1 dalecurtis Administrators  162830 Feb  7 18:03 avutil-51.dll
> 
> vs w/ static pthreads:
> 
> -rwxr-x--- 1 dalecurtis eng 982542 2012-02-07 17:35 avcodec-54.dll
> -rwxr-x--- 1 dalecurtis eng 189454 2012-02-07 17:35 avformat-54.dll
> -rwxr-x--- 1 dalecurtis eng 132622 2012-02-07 17:35 avutil-51.dll

Actually disregard that, we can drop static pthreads patch. The size problem
comes from -O2 not being respected with --add-cflags, I needed to use
--optflags.

[rbultje1, 2012-02-08 04:27:43]

Yeah, pthread patch can go away with w32threads, sorry for the late response.

As I said to Dale earlier, it may be worth briefly checking to make sure that
the different w32threads functions we use won't cause portability issues to
earlier versions of Windows (e.g. make sure we don't use a >=XP ABI/API if
Chrome needs to run on 2K, or >=Vista API/ABI if Chrome needs to run on XP).

[DaleCurtis, 2012-02-09 01:29:48]

Landing this patch.

There's still some binary/config rebuilds necessary after these land:

https://chromiumcodereview.appspot.com/9373002/
https://chromiumcodereview.appspot.com/9370003/

I'll take care of that in a TBR. As a reminder, these changes have no effect on
current ffmpeg at the moment.

Ilja: I fixed the 2012 nits as well.

http://codereview.chromium.org/9325049/diff/3018/chromium/config/Chrome/win/i...
File chromium/config/Chrome/win/ia32/config.h (right):

http://codereview.chromium.org/9325049/diff/3018/chromium/config/Chrome/win/i...
chromium/config/Chrome/win/ia32/config.h:56: #define HAVE_W32THREADS 1
On 2012/02/06 19:35:03, DaleCurtis wrote:
> On 2012/02/06 17:57:55, scherkus wrote:
> > !!!
> > 
> > that static pthreads patch inside of configure should be irrelevant if
ffmpeg
> > links directly to w32 threads
> > 
> > also: there's a bunch of crap and instructions under
./deps/third_party/mingw
> > and ./deps/third_party/pthreads-win32/ that can likely get deleted after
we're
> > done
> > 
> > care to make an AI of this somewhere?
> 
> Awesome, I'll drop the patch and see what happens on Windows. Sure, I'll file
an
> issue for it. 

Patch dropped in https://chromiumcodereview.appspot.com/9370003/