Fix timing out of perf test: Canvas/upload-canvas-2d-to-texture.html

Fix timing out of perf test: Canvas/upload-canvas-2d-to-texture.html

content_shell can not decode mov, so this CL makes canvas tests use mp4 file.
the desktop Perf bots (Windows, Mac, and Linux) do actually build Chrome-branded
binaries including all of the media codecs so H.264 encoded mp4 file can be
decoded.

bear-1280x720.mp4 is copied from chromium; src/media/test/data
Canvas video perf tests run on only the platform which can decode mp4 video.

BUG=242244, 358168
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=170521

[dshwang, 2014-03-31 19:26:56]

This CL fixes http://crbug.com/358168
However, I'm not sure it's right CL, so I ask some questions.

1. Which file extension is the best for perf tests?
ogv: chromium supports it, but I'm not sure this format take advantage of HW
decoding.
mp4: need Chrome branding and proprietary_codecs.
wepm: It seems to might be supported by only ChromeOS
http://www.chromium.org/audio-video

2. Can I copy file from src/media/test/data, which is governed by BSD?

3. How media test harness can test mp4, which needs Chrome branding and
proprietary_codecs?
media/test/data/rapid_video_change_test.html:     <video id='video' width=320
height=240 src='bear-1280x720.mp4'

[dshwang, 2014-03-31 19:30:48]

4. content_shell cannot handle .mov now, but IIRC few weeks ago content_shell
can handle it. Could you point out the relevant issue or CL if I'm right?

[Ken Russell (switch to Gerrit), 2014-03-31 22:32:28]

-jamesr, +tonyg, +others

This is a good point. It may be difficult to test the HW accelerated video
decoding path in anything except Chrome. I don't know if there are any codecs in
Chromium (compared to Chrome) which go down the HW accelerated decoding path.
There are existing problems with test coverage even on the correctness bots, not
just the perf bots.

CC'ing more people from Chromium's Speed Team for comment on including the new
video file (I think it'll be fine) and people from the Media Team for comment on
how to test the HW accelerated video decode path.

[Ami GONE FROM CHROMIUM, 2014-03-31 23:40:50]

On 2014/03/31 22:32:28, Ken Russell wrote:
> -jamesr, +tonyg, +others
> 
> This is a good point. It may be difficult to test the HW accelerated video
> decoding path in anything except Chrome. I don't know if there are any codecs
in
> Chromium (compared to Chrome) which go down the HW accelerated decoding path.
> There are existing problems with test coverage even on the correctness bots,
not
> just the perf bots.

VP8 video in WebM container is the only format that goes down the HW decode path
in chromium, and the only platform where that's likely to work is CrOS/ARM (and
Android, if you consider <video> tags playing remote WebRTC streams).

It's a bit silly though that HW h.264 decode isn't triggerable in chromium
(since the salient chromium-vs-chrome difference is whether we ship an h.264
_SW_ decoder); the only reason for it is that when we exclude h.264 SW decoder
we also exclude the .mp4 container parser, which is otherwise unencumbered. 
https://code.google.com/p/chromium/issues/detail?id=327115 is filed for
including .mp4 demux in chromium, which would allow testing h.264 decode in HW
in chromium.

[Ken Russell (switch to Gerrit), 2014-04-01 00:51:07]

On 2014/03/31 23:40:50, Ami Fischman wrote:
> On 2014/03/31 22:32:28, Ken Russell wrote:
> > -jamesr, +tonyg, +others
> > 
> > This is a good point. It may be difficult to test the HW accelerated video
> > decoding path in anything except Chrome. I don't know if there are any
codecs
> in
> > Chromium (compared to Chrome) which go down the HW accelerated decoding
path.
> > There are existing problems with test coverage even on the correctness bots,
> not
> > just the perf bots.
> 
> VP8 video in WebM container is the only format that goes down the HW decode
path
> in chromium, and the only platform where that's likely to work is CrOS/ARM
(and
> Android, if you consider <video> tags playing remote WebRTC streams).
> 
> It's a bit silly though that HW h.264 decode isn't triggerable in chromium
> (since the salient chromium-vs-chrome difference is whether we ship an h.264
> _SW_ decoder); the only reason for it is that when we exclude h.264 SW decoder
> we also exclude the .mp4 container parser, which is otherwise unencumbered. 
> https://code.google.com/p/chromium/issues/detail?id=327115 is filed for
> including .mp4 demux in chromium, which would allow testing h.264 decode in HW
> in chromium.

After talking with tonyg@, it's clear that the desktop Perf bots (Windows, Mac,
and Linux) do actually build Chrome-branded binaries including all of the media
codecs, so I believe this change will fix the reported issue.

LGTM from my standpoint. Dongseong, if this doesn't fix the tests, then please
add your new tests to PerformanceTests/Skipped until we figure out the best path
forward.

[dshwang, 2014-04-01 06:56:04]

Thank you for good opinion, kbr@, Ami, tonyg@.

On 2014/04/01 00:51:07, Ken Russell wrote:
> On 2014/03/31 23:40:50, Ami Fischman wrote:
> > It's a bit silly though that HW h.264 decode isn't triggerable in chromium
> > (since the salient chromium-vs-chrome difference is whether we ship an h.264
> > _SW_ decoder); the only reason for it is that when we exclude h.264 SW
decoder
> > we also exclude the .mp4 container parser, which is otherwise unencumbered. 
> > https://code.google.com/p/chromium/issues/detail?id=327115 is filed for
> > including .mp4 demux in chromium, which would allow testing h.264 decode in
HW
> > in chromium.

There is issue already what I want :)
 
> After talking with tonyg@, it's clear that the desktop Perf bots (Windows,
Mac,
> and Linux) do actually build Chrome-branded binaries including all of the
media
> codecs, so I believe this change will fix the reported issue.

wow, good to know.

> LGTM from my standpoint. Dongseong, if this doesn't fix the tests, then please
> add your new tests to PerformanceTests/Skipped until we figure out the best
path
> forward.

Yes, I'll do it.

[dshwang, 2014-04-01 06:57:59]

The CQ bit was checked by dongseong.hwang@intel.com

[commit-bot: I haz the power, 2014-04-01 06:58:09]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/dongseong.hwang@intel.com/219023009/1

[commit-bot: I haz the power, 2014-04-01 07:07:39]

Change committed as 170521