Revert of media: Add MediaOzonePlatform support

Revert of media: Add MediaOzonePlatform support (patchset #7 id:110001 of https://codereview.chromium.org/269673005/)

Reason for revert:
Not used at the moment.

Agreed with kalyan.kondapally@intel.com,
tiago.vignatti@intel.com and 
joone.hur@intel.com.

Original issue's description:
> media: Add MediaOzonePlatform support
> 
> This CL adds MediaOzonePlatform, a new Ozone component for abstracting media
> and related. In particular it adds CreateVideoDecodeAccelerator method so Ozone
> implementations can use that for abstracting video decoding acceleration (i.e.
> GPU based video decoding). Eventually MediaOzonePlatform will be used as well
> for many windowing systems abstractions related to media, e.g. video encode,
> audio, etc. We will add support for these others as needed.
> 
> Media platform is called and created on demand whenever a video playback is set
> to play. Different than ui::OzonePlatform methods, the one added in here is 
> non-pure virtual so the implementations can decide themselves whether a video 
> implementation is actually wanted, based on its hardware capabilities.
> 
> This work is aimed at internal implementations like Ozone-DRI, Ozone-test but
> also for externals like Ozone-Wayland. Different targets like Chromium Browser,
> Chrome OS, ChromeCast and others can now take advantage of it.
> 
> BUG=380884
> TEST=manually on Ozone-Wayland, using:
> 
>  $ export GYP_DEFINES='chromeos=0 use_ozone=1 proprietary_codecs=1 ffmpeg_branding=Chrome'
>  $ ninja -j16 -C out/Release content
> 
> and to run:
> 
>  ~/git/chromium/src/out/Debug$ ./chrome --no-sandbox --user-data-dir=/tmp/chrome --ignore-gpu-blacklist ../../third_party/WebKit/PerformanceTests/resources/bear-1280x720.mp4  --vmodule=*/ozone/ui*=3 --v=0
> 
> additionally, in Release builds you can start chrome with --disable-accelerated-video-decode to compare the results.
> 
> Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=276552

TBR=rjkroege@chromium.org,scherkus@chromium.org,dnicoara@chromium.org,spang@chromium.org,dongseong.hwang@intel.com,xhwang@chromium.org,tiago.vignatti@intel.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=380884

[mcasas, 2015-05-08 23:08:22]

Created Revert of media: Add MediaOzonePlatform support

[mcasas, 2015-05-09 00:23:20]

The CQ bit was unchecked by mcasas@chromium.org

[mcasas, 2015-05-09 00:23:20]

The CQ bit was checked by mcasas@chromium.org

[vignatti (out of this project), 2015-05-11 16:16:43]

yup, lgtm. Thanks mcasas!

[spang, 2015-05-11 17:08:11]

On 2015/05/08 23:08:22, mcasas wrote:
> Created Revert of media: Add MediaOzonePlatform support

Re: Lack of users, Chrome OS should move to this interface.

The fact that it doesn't consider the runtime platform (and assumes DRM) is a
layering violation.

[mcasas, 2015-05-11 17:30:00]

The CQ bit was unchecked by mcasas@chromium.org

[mcasas, 2015-05-11 17:30:05]

The CQ bit was checked by mcasas@chromium.org

[dshwang, 2015-05-14 16:21:09]

On 2015/05/11 17:08:11, spang wrote:
> On 2015/05/08 23:08:22, mcasas wrote:
> > Created Revert of media: Add MediaOzonePlatform support
> 
> Re: Lack of users, Chrome OS should move to this interface.
> 
> The fact that it doesn't consider the runtime platform (and assumes DRM) is a
> layering violation.

Chrome OS Freon uses VaapiVDA or V4L2Device already without this interface.
https://code.google.com/p/chromium/codesearch#chromium/src/content/common/gpu...

This interface remains for !chrome_os&&use_ozone, and currently lack of users.
Do you mean Chrome OS Freon should use this interface, instead of compile time
selection in GpuVideoDecodeAccelerator?

[spang, 2015-05-14 16:26:06]

On 2015/05/14 16:21:09, dshwang wrote:
> On 2015/05/11 17:08:11, spang wrote:
> > On 2015/05/08 23:08:22, mcasas wrote:
> > > Created Revert of media: Add MediaOzonePlatform support
> > 
> > Re: Lack of users, Chrome OS should move to this interface.
> > 
> > The fact that it doesn't consider the runtime platform (and assumes DRM) is
a
> > layering violation.
> 
> Chrome OS Freon uses VaapiVDA or V4L2Device already without this interface.
>
https://code.google.com/p/chromium/codesearch#chromium/src/content/common/gpu...
> 
> This interface remains for !chrome_os&&use_ozone, and currently lack of users.
> Do you mean Chrome OS Freon should use this interface, instead of compile time
> selection in GpuVideoDecodeAccelerator?

Yes, absolutely. The current code is wrong.

[kalyank, 2015-05-15 18:09:23]

On 2015/05/14 16:26:06, spang wrote:
> On 2015/05/14 16:21:09, dshwang wrote:
> > On 2015/05/11 17:08:11, spang wrote:
> >
>
https://code.google.com/p/chromium/codesearch#chromium/src/content/common/gpu...
> > 
> > This interface remains for !chrome_os&&use_ozone, and currently lack of
users.
> > Do you mean Chrome OS Freon should use this interface, instead of compile
time
> > selection in GpuVideoDecodeAccelerator?
> 
> Yes, absolutely. The current code is wrong.

Agree, however we should re-think the interface though. Ideally we want
something similar to what SurfaceFactory provides, a means to initialize the
native display and buffers.

[spang, 2015-05-15 18:12:34]

On 2015/05/15 18:09:23, kalyank wrote:
> On 2015/05/14 16:26:06, spang wrote:
> > On 2015/05/14 16:21:09, dshwang wrote:
> > > On 2015/05/11 17:08:11, spang wrote:
> > >
> >
>
https://code.google.com/p/chromium/codesearch#chromium/src/content/common/gpu...
> > > 
> > > This interface remains for !chrome_os&&use_ozone, and currently lack of
> users.
> > > Do you mean Chrome OS Freon should use this interface, instead of compile
> time
> > > selection in GpuVideoDecodeAccelerator?
> > 
> > Yes, absolutely. The current code is wrong.
> 
> Agree, however we should re-think the interface though. Ideally we want
> something similar to what SurfaceFactory provides, a means to initialize the
> native display and buffers.

SGTM.

[Sergiy Byelozyorov, 2015-05-19 12:25:39]

The CQ bit was unchecked by sergiyb@chromium.org

[Sergiy Byelozyorov, 2015-05-19 12:27:21]

On 2015/05/15 18:12:34, spang wrote:
> On 2015/05/15 18:09:23, kalyank wrote:
> > On 2015/05/14 16:26:06, spang wrote:
> > > On 2015/05/14 16:21:09, dshwang wrote:
> > > > On 2015/05/11 17:08:11, spang wrote:
> > > >
> > >
> >
>
https://code.google.com/p/chromium/codesearch#chromium/src/content/common/gpu...
> > > > 
> > > > This interface remains for !chrome_os&&use_ozone, and currently lack of
> > users.
> > > > Do you mean Chrome OS Freon should use this interface, instead of
compile
> > time
> > > > selection in GpuVideoDecodeAccelerator?
> > > 
> > > Yes, absolutely. The current code is wrong.
> > 
> > Agree, however we should re-think the interface though. Ideally we want
> > something similar to what SurfaceFactory provides, a means to initialize the
> > native display and buffers.
> 
> SGTM.

Unchecked CQ bit, because this revert is for a CL that is too old and doesn't
have the "project" field. Please re-upload it as a new CL

git cl issue 0
git cl upload

or land manually.

[mcasas, 2015-05-22 02:32:47]

On 2015/05/19 12:27:21, Sergiy Byelozyorov wrote:
> On 2015/05/15 18:12:34, spang wrote:
> > On 2015/05/15 18:09:23, kalyank wrote:
> > > On 2015/05/14 16:26:06, spang wrote:
> > > > On 2015/05/14 16:21:09, dshwang wrote:
> > > > > On 2015/05/11 17:08:11, spang wrote:
> > > > >
> > > >
> > >
> >
>
https://code.google.com/p/chromium/codesearch#chromium/src/content/common/gpu...
> > > > > 
> > > > > This interface remains for !chrome_os&&use_ozone, and currently lack
of
> > > users.
> > > > > Do you mean Chrome OS Freon should use this interface, instead of
> compile
> > > time
> > > > > selection in GpuVideoDecodeAccelerator?
> > > > 
> > > > Yes, absolutely. The current code is wrong.
> > > 
> > > Agree, however we should re-think the interface though. Ideally we want
> > > something similar to what SurfaceFactory provides, a means to initialize
the
> > > native display and buffers.
> > 
> > SGTM.
> 
> Unchecked CQ bit, because this revert is for a CL that is too old and doesn't
> have the "project" field. Please re-upload it as a new CL
> 
> git cl issue 0
> git cl upload
> 
> or land manually.

This issue doesn't apply cleanly anymore :-(
Needs smart merge. Closing this CL in the hope
that soon it will be smart-reverted.