[go: nahoru, domu]

AcceleratedVideoDecoder: introduce CodecPicture and remove VaapiDecodeSurface

Generic, platform-independent decoders - {H264,VP8,VP9}Decoder - operate on
generic Picture classes - {H264,VP8,VP9}Picture - and use them to communicate
with platform-specific Accelerators.

Accelerators augment these Picture classes with platform-specific metadata
in order to process them. This includes platform-specific representations
of buffers used as targets for decoding a given picture, such as VASurface
for VaapiVDA.

This platform-specific metadata is encapsulated in Accelerator-specific
{Vaapi,V4L2}DecodeSurface classes.

To tie {Vaapi,V4L2}DecodeSurface to each type of Picture class, a set of
classes: {Vaapi,V4L2}{H624,VP8,VP9}Picture is introduced. They are subclasses
of {H264,VP8,VP9}Picture classes and own {Vaapi,V4L2}DecodeSurface classes.

For VaapiVDA, the relationship is:

{H264,VP8,VP9}Picture
         ^    |
         |     -[owns] -> H264/VP8/VP9 specific metadata
      [is a]
         |
Vaapi{H624,VP8,VP9}Picture
              |
               -[owns]-> VaapiDecodeSurface
                           |
                            -[owns]-> common Picture metadata(visible_rect,...}
                                      platform-specific metadata(VASurface)

In case of V4L2VDA:

{H264,VP8,VP9}Picture
         ^    |
         |     -[owns] -> H264/VP8/VP9 specific metadata
      [is a]
         |
V4L2{H624,VP8,VP9}Picture
              |
               -[owns]-> V4L2DecodeSurface
                           |
                            -[owns]-> common Picture metadata(visible_rect,...)
                                      platform-specific metadata:
                                        ({input,output}_record, config_store...)

However, as {Vaapi,V4L2}{H624,VP8,VP9}Picture are platform-specific already,
we can eliminate one level of ownership indirection by removing
{Vaapi,V4L2}DecodeSurface classes, as well as avoid having the same common
Picture metadata in each of the 6 {Vaapi,V4L2}{H624,VP8,VP9}Picture classes
to further simplify the design:

   CodecPicture
         ^    |
	 |     -[owns] -> common Picture metadata
      [is a]
	 |
{H264,VP8,VP9}Picture
         ^    |
	 |     -[owns] -> H264/VP8/VP9-specific metadata
      [is a]
	 |
Vaapi{H624,VP8,VP9}Picture
              |
	       -[owns] -> platform-specific metadata(VASurface)

Moreover, this will further allow us to reuse the picture classes on all
levels of the hierarchy (including {V4L2,Vaapi}{H624,VP8,VP9}Picture
classes) for the upcoming, new AcceleratedVideoEncoder framework, without
having to create a new set of encoder-only {Vaapi,V4L2}EncodeSurface classes.

Removal of V4L2DecodeSurface is left for a follow-up CL.

BUG=703988
TEST=VDA unittests, video playback in Chrome, video playback in ARC++

Cq-Include-Trybots: luci.chromium.try:linux_optional_gpu_tests_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: I86f30adf4b5754fffb89eb3769b11d01d8e04814
Reviewed-on: https://chromium-review.googlesource.com/947545
Commit-Queue: Pawel Osciak <posciak@chromium.org>
Reviewed-by: Miguel Casas <mcasas@chromium.org>
Reviewed-by: Kuang-che Wu <kcwu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#543995}
32 files changed