Clean up video frame sizes, types in Video Decode API

ppapi/c/dev/pp_video_dev.h

Index: ppapi/c/dev/pp_video_dev.h
diff --git a/ppapi/c/dev/pp_video_dev.h b/ppapi/c/dev/pp_video_dev.h
index 49eec11e3c888ba9119bcb6f2fa8c6be972326e5..d0e3c77d74082e3369a768d4c8770a75707664b2 100644
--- a/ppapi/c/dev/pp_video_dev.h
+++ b/ppapi/c/dev/pp_video_dev.h
@@ -153,16 +153,6 @@ enum PP_H264PayloadFormat_Dev {
 };
 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.
@@ -210,26 +200,12 @@ struct PP_SysmemBuffer_Dev {
 };
 
 // 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