Zero initialize the first allocation of a VideoFrame.

Zero initialize the first allocation of a VideoFrame.

Replicates FFmpeg's behavior for frame allocation.  They do not zero
the frame on subsequent pool reuse, so I have not done so either.

BUG=390941, 390944, 390945
TEST=new unittest.

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

[DaleCurtis, 2014-07-10 23:00:32]

It's a little tricky to follow the flow to where FFmpeg eventually zeros out the
buffers, so here's the details:

AVBufferPools for video are initialized to use av_buffer_allocz() unless memory
poisoning is enabled (not used by Chrome):
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/ffmpeg...
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/ffmpeg...

From there, at the time of a new frame, video_get_buffer() requests one from the
pool:
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/ffmpeg...

If no frames exist in the pool the alloc() specified during pool initialization
is called:
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/ffmpeg...

I've put this code in VideoFrame since we need to zero everything, including the
padding details of the frame which are not exposed to clients currently (it's
not sufficient to fix the issues otherwise).  I could instead add a
VideoFrame::Zero() method which clients can call, but it's unclear what that
means when the data isn't owned by the VideoFrame.  Suggestions welcome.

[scherkus (not reviewing), 2014-07-11 00:57:48]

OOC did we confirm the msan reports are fixed?

[DaleCurtis, 2014-07-11 01:11:07]

Yeah, I built an msan build locally and confirmed the third bug is fixed.  The
other two didn't repro under a PipelineIntegrationTest, but since they all come
from the same root allocation it should fix them all.

[scherkus (not reviewing), 2014-07-11 19:26:28]

lgtm

[DaleCurtis, 2014-07-11 20:23:36]

The CQ bit was checked by dalecurtis@chromium.org

[commit-bot: I haz the power, 2014-07-11 20:24:30]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/dalecurtis@chromium.org/383893002/1

[commit-bot: I haz the power, 2014-07-12 00:06:17]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  win_chromium_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/win_chromium_rel/buil...)

[commit-bot: I haz the power, 2014-07-12 01:53:32]

Change committed as 282775