Clean up video frame sizes, types in Video Decode API

ppapi/c/dev/pp_video_dev.h

 /* Copyright (c) 2011 The Chromium Authors. All rights reserved.
  * Use of this source code is governed by a BSD-style license that can be
  * found in the LICENSE file.
  */
 #ifndef PPAPI_C_DEV_PP_VIDEO_DEV_H_
 #define PPAPI_C_DEV_PP_VIDEO_DEV_H_
 
 #include "ppapi/c/dev/ppb_opengles_dev.h"
 #include "ppapi/c/pp_bool.h"
 #include "ppapi/c/pp_instance.h"
@@ skipping 135 matching lines @@
   PP_H264PAYLOADFORMAT_ONE_NALU_PER_BUFFER = 1 << 1,
   // NALU separated by 1-byte interleaved length field.
   PP_H264PAYLOADFORMAT_ONE_BYTE_INTERLEAVED_LENGTH = 1 << 2,
   // NALU separated by 2-byte interleaved length field.
   PP_H264PAYLOADFORMAT_TWO_BYTE_INTERLEAVED_LENGTH = 1 << 3,
   // NALU separated by 4-byte interleaved length field.
   PP_H264PAYLOADFORMAT_FOUR_BYTE_INTERLEAVED_LENGTH = 1 << 4
 };
 PP_COMPILE_ASSERT_ENUM_SIZE_IN_BYTES(PP_H264PayloadFormat_Dev, 4);
 
-// Enumeration to determine which type of memory for buffer is used.
-enum PP_PictureBufferType_Dev {
-  PP_PICTUREBUFFERTYPE_NONE = 0,
-  // System memory a.k.a. RAM.
-  PP_PICTUREBUFFERTYPE_SYSTEM = 1,
-  // GLES texture allocated using OpenGL ES APIs.
-  PP_PICTUREBUFFERTYPE_GLESTEXTURE = 1 << 1
-};
-PP_COMPILE_ASSERT_ENUM_SIZE_IN_BYTES(PP_PictureBufferType_Dev, 4);
-

[Ville-Mikko Rautio, 2011/05/17 08:58:49]

How do we signal in the configuration the case where decoder supports only
system memory buffers or GLES textures, i.e. not both?

[vrk (LEFT CHROMIUM), 2011/05/23 18:20:29]

I don't think this is a valid case. To the decoder, system memory versus GLES
texture is really just a difference between where to write bytes. A GPU decoder
will always be able to decode into textures, and it will also be able to decode
into shared memory.

[vmr, 2011/05/24 07:11:11]

Even though theoretically these differences are just different decoding targets
I do think there is difference between the cases in practice. For example, in
case of textures OMX decoder goes into EGLImage decoding path whereas when
decoding to system memory there is separate decoding path used. In this case the
functions I am talking about are OMX_UseEGLImage and OMX_UseBuffer. I know for
fact that there are number of OMX implementations out there in the world that
support only the latter. I know our first target has the OMX_UseEGLImage but it
will be a problem for other vendors who may try to create Chrome OS devices.

 // The data structure for video bitstream buffer.
 struct PP_VideoBitstreamBuffer_Dev {
   // Client-specified identifier for the bitstream buffer.
   int32_t id;
 
   // Buffer to hold the bitstream data. Should be allocated using the PPB_Buffer
   // interface for consistent interprocess behaviour.
   PP_Resource data;
 
   // Size of the bitstream contained in buffer (in bytes).
@@ skipping 27 matching lines @@
 struct PP_SysmemBuffer_Dev {
   // Resource representing system memory from shared memory address space.
   // Use PPB_Buffer_Dev interface to handle this resource.
   PP_Resource data;
 
   // Information about the buffer.
   struct PP_BufferInfo_Dev info;
 };
 
 // Structure to describe a decoded output frame.
-// The decoded pixels will always begin flush with the upper left-hand corner
-// of the buffer (0, 0).
 struct PP_Picture_Dev {
   // ID of the picture buffer where the picture is stored.
   int32_t picture_buffer_id;
 
   // ID of the bitstream from which this data was decoded.
   int32_t bitstream_buffer_id;
-
-  // Visible size of the picture.
-  // This describes the dimensions of the picture that is intended to be
-  // displayed from the decoded output.
-  struct PP_Size visible_size;
-
-  // Decoded size of the picture.
-  // This describes the dimensions of the decoded output. This may be slightly
-  // larger than the visible size because the stride is sometimes larger than
-  // the width of the output. The plugin should handle rendering the frame
-  // appropriately with respect to the sizes.
-  struct PP_Size decoded_size;
 };
 
 // Enumeration for error events that may be reported through
 // PP_VideoDecodeErrorHandler_Func_Dev callback function to the plugin. Default
 // error handling functionality expected from the plugin is to Flush and Destroy
 // the decoder.
 enum PP_VideoDecodeError_Dev {
   PP_VIDEODECODEERROR_NONE = 0,
   // Decoder has not been initialized and configured properly.
   PP_VIDEODECODEERROR_UNINITIALIZED,
   // Decoder does not support feature of configuration or bitstream.
   PP_VIDEODECODEERROR_UNSUPPORTED,
   // Decoder did not get valid input.
   PP_VIDEODECODERERROR_INVALIDINPUT,
   // Failure in memory allocation or mapping.
   PP_VIDEODECODERERROR_MEMFAILURE,
   // Decoder was given bitstream that would result in output pictures but it
   // has not been provided buffers to do all this.
   PP_VIDEODECODEERROR_INSUFFICIENT_BUFFERS,
   // Decoder cannot continue operation due to insufficient resources for the
   // current configuration.
   PP_VIDEODECODEERROR_INSUFFICIENTRESOURCES,
   // Decoder hardware has reported hardware error.
   PP_VIDEODECODEERROR_HARDWARE
 };
 PP_COMPILE_ASSERT_ENUM_SIZE_IN_BYTES(PP_VideoDecodeError_Dev, 4);
 
 #endif  /* PPAPI_C_DEV_PP_VIDEO_DEV_H_ */