• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
1 /*
2  * Copyright (C) 2009 The Android Open Source Project
3  *
4  * Licensed under the Apache License, Version 2.0 (the "License");
5  * you may not use this file except in compliance with the License.
6  * You may obtain a copy of the License at
7  *
8  *      http://www.apache.org/licenses/LICENSE-2.0
9  *
10  * Unless required by applicable law or agreed to in writing, software
11  * distributed under the License is distributed on an "AS IS" BASIS,
12  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
13  * See the License for the specific language governing permissions and
14  * limitations under the License.
15  */
16 
17 #ifndef HARDWARE_API_H_
18 
19 #define HARDWARE_API_H_
20 
21 #include <media/hardware/OMXPluginBase.h>
22 #include <media/hardware/MetadataBufferType.h>
23 #include <cutils/native_handle.h>
24 #include <utils/RefBase.h>
25 
26 #include "VideoAPI.h"
27 
28 #include <OMX_Component.h>
29 
30 struct ANativeWindowBuffer;
31 
32 namespace android {
33 
34 // This structure is used to enable Android native buffer use for either
35 // graphic buffers or secure buffers.
36 //
37 // TO CONTROL ANDROID GRAPHIC BUFFER USAGE:
38 //
39 // A pointer to this struct is passed to the OMX_SetParameter when the extension
40 // index for the 'OMX.google.android.index.enableAndroidNativeBuffers' extension
41 // is given.
42 //
43 // When Android native buffer use is disabled for a port (the default state),
44 // the OMX node should operate as normal, and expect UseBuffer calls to set its
45 // buffers.  This is the mode that will be used when CPU access to the buffer is
46 // required.
47 //
48 // When Android native buffer use has been enabled for a given port, the video
49 // color format for the port is to be interpreted as an Android pixel format
50 // rather than an OMX color format.  Enabling Android native buffers may also
51 // change how the component receives the native buffers.  If store-metadata-mode
52 // is enabled on the port, the component will receive the buffers as specified
53 // in the section below. Otherwise, unless the node supports the
54 // 'OMX.google.android.index.useAndroidNativeBuffer2' extension, it should
55 // expect to receive UseAndroidNativeBuffer calls (via OMX_SetParameter) rather
56 // than UseBuffer calls for that port.
57 //
58 // TO CONTROL ANDROID SECURE BUFFER USAGE:
59 //
60 // A pointer to this struct is passed to the OMX_SetParameter when the extension
61 // index for the 'OMX.google.android.index.allocateNativeHandle' extension
62 // is given.
63 //
64 // When native handle use is disabled for a port (the default state),
65 // the OMX node should operate as normal, and expect AllocateBuffer calls to
66 // return buffer pointers. This is the mode that will be used for non-secure
67 // buffers if component requires allocate buffers instead of use buffers.
68 //
69 // When native handle use has been enabled for a given port, the component
70 // shall allocate native_buffer_t objects containing  that can be passed between
71 // processes using binder. This is the mode that will be used for secure buffers.
72 // When an OMX component allocates native handle for buffers, it must close and
73 // delete that handle when it frees those buffers. Even though pBuffer will point
74 // to a native handle, nFilledLength, nAllocLength and nOffset will correspond
75 // to the data inside the opaque buffer.
76 struct EnableAndroidNativeBuffersParams {
77     OMX_U32 nSize;
78     OMX_VERSIONTYPE nVersion;
79     OMX_U32 nPortIndex;
80     OMX_BOOL enable;
81 };
82 
83 typedef struct EnableAndroidNativeBuffersParams AllocateNativeHandleParams;
84 
85 // A pointer to this struct is passed to OMX_SetParameter() when the extension index
86 // "OMX.google.android.index.storeMetaDataInBuffers" or
87 // "OMX.google.android.index.storeANWBufferInMetadata" is given.
88 //
89 // When meta data is stored in the video buffers passed between OMX clients
90 // and OMX components, interpretation of the buffer data is up to the
91 // buffer receiver, and the data may or may not be the actual video data, but
92 // some information helpful for the receiver to locate the actual data.
93 // The buffer receiver thus needs to know how to interpret what is stored
94 // in these buffers, with mechanisms pre-determined externally. How to
95 // interpret the meta data is outside of the scope of this parameter.
96 //
97 // Currently, this is used to pass meta data from video source (camera component, for instance) to
98 // video encoder to avoid memcpying of input video frame data, as well as to pass dynamic output
99 // buffer to video decoder. To do this, bStoreMetaData is set to OMX_TRUE.
100 //
101 // If bStoreMetaData is set to false, real YUV frame data will be stored in input buffers, and
102 // the output buffers contain either real YUV frame data, or are themselves native handles as
103 // directed by enable/use-android-native-buffer parameter settings.
104 // In addition, if no OMX_SetParameter() call is made on a port with the corresponding extension
105 // index, the component should not assume that the client is not using metadata mode for the port.
106 //
107 // If the component supports this using the "OMX.google.android.index.storeANWBufferInMetadata"
108 // extension and bStoreMetaData is set to OMX_TRUE, data is passed using the VideoNativeMetadata
109 // layout as defined below. Each buffer will be accompanied by a fence. The fence must signal
110 // before the buffer can be used (e.g. read from or written into). When returning such buffer to
111 // the client, component must provide a new fence that must signal before the returned buffer can
112 // be used (e.g. read from or written into). The component owns the incoming fenceFd, and must close
113 // it when fence has signaled. The client will own and close the returned fence file descriptor.
114 //
115 // If the component supports this using the "OMX.google.android.index.storeMetaDataInBuffers"
116 // extension and bStoreMetaData is set to OMX_TRUE, data is passed using VideoGrallocMetadata
117 // (the layout of which is the VideoGrallocMetadata defined below). Camera input can be also passed
118 // as "CameraSource", the layout of which is vendor dependent.
119 //
120 // Metadata buffers are registered with the component using UseBuffer calls, or can be allocated
121 // by the component for encoder-metadata-output buffers.
122 struct StoreMetaDataInBuffersParams {
123     OMX_U32 nSize;
124     OMX_VERSIONTYPE nVersion;
125     OMX_U32 nPortIndex;
126     OMX_BOOL bStoreMetaData;
127 };
128 
129 // Meta data buffer layout used to transport output frames to the decoder for
130 // dynamic buffer handling.
131 struct VideoGrallocMetadata {
132     MetadataBufferType eType;               // must be kMetadataBufferTypeGrallocSource
133 #ifdef OMX_ANDROID_COMPILE_AS_32BIT_ON_64BIT_PLATFORMS
134     OMX_PTR pHandle;
135 #else
136     buffer_handle_t pHandle;
137 #endif
138 };
139 
140 // Legacy name for VideoGrallocMetadata struct.
141 struct VideoDecoderOutputMetaData : public VideoGrallocMetadata {};
142 
143 struct VideoNativeMetadata {
144     MetadataBufferType eType;               // must be kMetadataBufferTypeANWBuffer
145 #ifdef OMX_ANDROID_COMPILE_AS_32BIT_ON_64BIT_PLATFORMS
146     OMX_PTR pBuffer;
147 #else
148     struct ANativeWindowBuffer* pBuffer;
149 #endif
150     int nFenceFd;                           // -1 if unused
151 };
152 
153 // Meta data buffer layout for passing a native_handle to codec
154 struct VideoNativeHandleMetadata {
155     MetadataBufferType eType;               // must be kMetadataBufferTypeNativeHandleSource
156 
157 #ifdef OMX_ANDROID_COMPILE_AS_32BIT_ON_64BIT_PLATFORMS
158     OMX_PTR pHandle;
159 #else
160     native_handle_t *pHandle;
161 #endif
162 };
163 
164 // A pointer to this struct is passed to OMX_SetParameter() when the extension
165 // index "OMX.google.android.index.prepareForAdaptivePlayback" is given.
166 //
167 // This method is used to signal a video decoder, that the user has requested
168 // seamless resolution change support (if bEnable is set to OMX_TRUE).
169 // nMaxFrameWidth and nMaxFrameHeight are the dimensions of the largest
170 // anticipated frames in the video.  If bEnable is OMX_FALSE, no resolution
171 // change is expected, and the nMaxFrameWidth/Height fields are unused.
172 //
173 // If the decoder supports dynamic output buffers, it may ignore this
174 // request.  Otherwise, it shall request resources in such a way so that it
175 // avoids full port-reconfiguration (due to output port-definition change)
176 // during resolution changes.
177 //
178 // DO NOT USE THIS STRUCTURE AS IT WILL BE REMOVED.  INSTEAD, IMPLEMENT
179 // METADATA SUPPORT FOR VIDEO DECODERS.
180 struct PrepareForAdaptivePlaybackParams {
181     OMX_U32 nSize;
182     OMX_VERSIONTYPE nVersion;
183     OMX_U32 nPortIndex;
184     OMX_BOOL bEnable;
185     OMX_U32 nMaxFrameWidth;
186     OMX_U32 nMaxFrameHeight;
187 };
188 
189 // A pointer to this struct is passed to OMX_SetParameter when the extension
190 // index for the 'OMX.google.android.index.useAndroidNativeBuffer' extension is
191 // given.  This call will only be performed if a prior call was made with the
192 // 'OMX.google.android.index.enableAndroidNativeBuffers' extension index,
193 // enabling use of Android native buffers.
194 struct UseAndroidNativeBufferParams {
195     OMX_U32 nSize;
196     OMX_VERSIONTYPE nVersion;
197     OMX_U32 nPortIndex;
198     OMX_PTR pAppPrivate;
199     OMX_BUFFERHEADERTYPE **bufferHeader;
200     const sp<ANativeWindowBuffer>& nativeBuffer;
201 };
202 
203 // A pointer to this struct is passed to OMX_GetParameter when the extension
204 // index for the 'OMX.google.android.index.getAndroidNativeBufferUsage'
205 // extension is given.  The usage bits returned from this query will be used to
206 // allocate the Gralloc buffers that get passed to the useAndroidNativeBuffer
207 // command.
208 struct GetAndroidNativeBufferUsageParams {
209     OMX_U32 nSize;              // IN
210     OMX_VERSIONTYPE nVersion;   // IN
211     OMX_U32 nPortIndex;         // IN
212     OMX_U32 nUsage;             // OUT
213 };
214 
215 // An enum OMX_COLOR_FormatAndroidOpaque to indicate an opaque colorformat
216 // is declared in media/stagefright/openmax/OMX_IVCommon.h
217 // This will inform the encoder that the actual
218 // colorformat will be relayed by the GRalloc Buffers.
219 // OMX_COLOR_FormatAndroidOpaque  = 0x7F000001,
220 
221 // A pointer to this struct is passed to OMX_SetParameter when the extension
222 // index for the 'OMX.google.android.index.prependSPSPPSToIDRFrames' extension
223 // is given.
224 // A successful result indicates that future IDR frames will be prefixed by
225 // SPS/PPS.
226 struct PrependSPSPPSToIDRFramesParams {
227     OMX_U32 nSize;
228     OMX_VERSIONTYPE nVersion;
229     OMX_BOOL bEnable;
230 };
231 
232 // A pointer to this struct is passed to OMX_GetParameter when the extension
233 // index for the 'OMX.google.android.index.describeColorFormat'
234 // extension is given.  This method can be called from any component state
235 // other than invalid.  The color-format, frame width/height, and stride/
236 // slice-height parameters are ones that are associated with a raw video
237 // port (input or output), but the stride/slice height parameters may be
238 // incorrect. bUsingNativeBuffers is OMX_TRUE if native android buffers will
239 // be used (while specifying this color format).
240 //
241 // The component shall fill out the MediaImage structure that
242 // corresponds to the described raw video format, and the potentially corrected
243 // stride and slice-height info.
244 //
245 // The behavior is slightly different if bUsingNativeBuffers is OMX_TRUE,
246 // though most implementations can ignore this difference. When using native buffers,
247 // the component may change the configured color format to an optimized format.
248 // Additionally, when allocating these buffers for flexible usecase, the framework
249 // will set the SW_READ/WRITE_OFTEN usage flags. In this case (if bUsingNativeBuffers
250 // is OMX_TRUE), the component shall fill out the MediaImage information for the
251 // scenario when these SW-readable/writable buffers are locked using gralloc_lock.
252 // Note, that these buffers may also be locked using gralloc_lock_ycbcr, which must
253 // be supported for vendor-specific formats.
254 //
255 // For non-YUV packed planar/semiplanar image formats, or if bUsingNativeBuffers
256 // is OMX_TRUE and the component does not support this color format with native
257 // buffers, the component shall set mNumPlanes to 0, and mType to MEDIA_IMAGE_TYPE_UNKNOWN.
258 
259 // @deprecated: use DescribeColorFormat2Params
260 struct DescribeColorFormat2Params;
261 struct DescribeColorFormatParams {
262     OMX_U32 nSize;
263     OMX_VERSIONTYPE nVersion;
264     // input: parameters from OMX_VIDEO_PORTDEFINITIONTYPE
265     OMX_COLOR_FORMATTYPE eColorFormat;
266     OMX_U32 nFrameWidth;
267     OMX_U32 nFrameHeight;
268     OMX_U32 nStride;
269     OMX_U32 nSliceHeight;
270     OMX_BOOL bUsingNativeBuffers;
271 
272     // output: fill out the MediaImage fields
273     MediaImage sMediaImage;
274 
275     explicit DescribeColorFormatParams(const DescribeColorFormat2Params&); // for internal use only
276 };
277 
278 // A pointer to this struct is passed to OMX_GetParameter when the extension
279 // index for the 'OMX.google.android.index.describeColorFormat2'
280 // extension is given. This is operationally the same as DescribeColorFormatParams
281 // but can be used for HDR and RGBA/YUVA formats.
282 struct DescribeColorFormat2Params {
283     OMX_U32 nSize;
284     OMX_VERSIONTYPE nVersion;
285     // input: parameters from OMX_VIDEO_PORTDEFINITIONTYPE
286     OMX_COLOR_FORMATTYPE eColorFormat;
287     OMX_U32 nFrameWidth;
288     OMX_U32 nFrameHeight;
289     OMX_U32 nStride;
290     OMX_U32 nSliceHeight;
291     OMX_BOOL bUsingNativeBuffers;
292 
293     // output: fill out the MediaImage2 fields
294     MediaImage2 sMediaImage;
295 
296     void initFromV1(const DescribeColorFormatParams&); // for internal use only
297 };
298 
299 // A pointer to this struct is passed to OMX_SetParameter or OMX_GetParameter
300 // when the extension index for the
301 // 'OMX.google.android.index.configureVideoTunnelMode' extension is  given.
302 // If the extension is supported then tunneled playback mode should be supported
303 // by the codec. If bTunneled is set to OMX_TRUE then the video decoder should
304 // operate in "tunneled" mode and output its decoded frames directly to the
305 // sink. In this case nAudioHwSync is the HW SYNC ID of the audio HAL Output
306 // stream to sync the video with. If bTunneled is set to OMX_FALSE, "tunneled"
307 // mode should be disabled and nAudioHwSync should be ignored.
308 // OMX_GetParameter is used to query tunneling configuration. bTunneled should
309 // return whether decoder is operating in tunneled mode, and if it is,
310 // pSidebandWindow should contain the codec allocated sideband window handle.
311 struct ConfigureVideoTunnelModeParams {
312     OMX_U32 nSize;              // IN
313     OMX_VERSIONTYPE nVersion;   // IN
314     OMX_U32 nPortIndex;         // IN
315     OMX_BOOL bTunneled;         // IN/OUT
316     OMX_U32 nAudioHwSync;       // IN
317     OMX_PTR pSidebandWindow;    // OUT
318 };
319 
320 // Color space description (aspects) parameters.
321 // This is passed via OMX_SetConfig or OMX_GetConfig to video encoders and decoders when the
322 // 'OMX.google.android.index.describeColorAspects' extension is given. Component SHALL behave
323 // as described below if it supports this extension.
324 //
325 // bDataSpaceChanged and bRequestingDataSpace is assumed to be OMX_FALSE unless noted otherwise.
326 //
327 // VIDEO ENCODERS: the framework uses OMX_SetConfig to specify color aspects of the coded video.
328 // This may happen:
329 //   a) before the component transitions to idle state
330 //   b) before the input frame is sent via OMX_EmptyThisBuffer in executing state
331 //   c) during execution, just before an input frame with a different color aspect information
332 //      is sent.
333 //
334 // The framework also uses OMX_GetConfig to
335 //   d) verify the color aspects that will be written to the stream
336 //   e) (optional) verify the color aspects that should be reported to the container for a
337 //      given dataspace/pixelformat received
338 //
339 // 1. Encoders SHOULD maintain an internal color aspect state, initialized to Unspecified values.
340 //    This represents the values that will be written into the bitstream.
341 // 2. Upon OMX_SetConfig, they SHOULD update their internal state to the aspects received
342 //    (including Unspecified values). For specific aspect values that are not supported by the
343 //    codec standard, encoders SHOULD substitute Unspecified values; or they MAY use a suitable
344 //    alternative (e.g. to suggest the use of BT.709 EOTF instead of SMPTE 240M.)
345 // 3. OMX_GetConfig SHALL return the internal state (values that will be written).
346 // 4. OMX_SetConfig SHALL always succeed before receiving the first frame. It MAY fail afterwards,
347 //    but only if the configured values would change AND the component does not support updating the
348 //    color information to those values mid-stream. If component supports updating a portion of
349 //    the color information, those values should be updated in the internal state, and OMX_SetConfig
350 //    SHALL succeed. Otherwise, the internal state SHALL remain intact and OMX_SetConfig SHALL fail
351 //    with OMX_ErrorUnsupportedSettings.
352 // 5. When the framework receives an input frame with an unexpected dataspace, it will query
353 //    encoders for the color aspects that should be reported to the container using OMX_GetConfig
354 //    with bDataSpaceChanged set to OMX_TRUE, and nPixelFormat/nDataSpace containing the new
355 //    format/dataspace values. This allows vendors to use extended dataspace during capture and
356 //    composition (e.g. screenrecord) - while performing color-space conversion inside the encoder -
357 //    and encode and report a different color-space information in the bitstream/container.
358 //    sColorAspects contains the requested color aspects by the client for reference, which may
359 //    include aspects not supported by the encoding. This is used together with guidance for
360 //    dataspace selection; see 6. below.
361 //
362 // VIDEO DECODERS: the framework uses OMX_SetConfig to specify the default color aspects to use
363 // for the video.
364 // This may happen:
365 //   a) before the component transitions to idle state
366 //   b) during execution, when the resolution or the default color aspects change.
367 //
368 // The framework also uses OMX_GetConfig to
369 //   c) get the final color aspects reported by the coded bitstream after taking the default values
370 //      into account.
371 //
372 // 1. Decoders should maintain two color aspect states - the default state as reported by the
373 //    framework, and the coded state as reported by the bitstream - as each state can change
374 //    independently from the other.
375 // 2. Upon OMX_SetConfig, it SHALL update its default state regardless of whether such aspects
376 //    could be supplied by the component bitstream. (E.g. it should blindly support all enumeration
377 //    values, even unknown ones, and the Other value). This SHALL always succeed.
378 // 3. Upon OMX_GetConfig, the component SHALL return the final color aspects by replacing
379 //    Unspecified coded values with the default values. This SHALL always succeed.
380 // 4. Whenever the component processes color aspect information in the bitstream even with an
381 //    Unspecified value, it SHOULD update its internal coded state with that information just before
382 //    the frame with the new information would be outputted, and the component SHALL signal an
383 //    OMX_EventPortSettingsChanged event with data2 set to the extension index.
384 // NOTE: Component SHOULD NOT signal a separate event purely for color aspect change, if it occurs
385 //    together with a port definition (e.g. size) or crop change.
386 // 5. If the aspects a component encounters in the bitstream cannot be represented with enumeration
387 //    values as defined below, the component SHALL set those aspects to Other. Restricted values in
388 //    the bitstream SHALL be treated as defined by the relevant bitstream specifications/standards,
389 //    or as Unspecified, if not defined.
390 //
391 // BOTH DECODERS AND ENCODERS: the framework uses OMX_GetConfig during idle and executing state to
392 //   f) (optional) get guidance for the dataspace to set for given color aspects, by setting
393 //      bRequestingDataSpace to OMX_TRUE. The component SHALL return OMX_ErrorUnsupportedSettings
394 //      IF it does not support this request.
395 //
396 // 6. This is an information request that can happen at any time, independent of the normal
397 //    configuration process. This allows vendors to use extended dataspace during capture, playback
398 //    and composition - while performing color-space conversion inside the component. Component
399 //    SHALL set the desired dataspace into nDataSpace. Otherwise, it SHALL return
400 //    OMX_ErrorUnsupportedSettings to let the framework choose a nearby standard dataspace.
401 //
402 // 6.a. For encoders, this query happens before the first frame is received using surface encoding.
403 //    This allows the encoder to use a specific dataspace for the color aspects (e.g. because the
404 //    device supports additional dataspaces, or because it wants to perform color-space extension
405 //    to facilitate a more optimal rendering/capture pipeline.).
406 //
407 // 6.b. For decoders, this query happens before the first frame, and every time the color aspects
408 //    change, while using surface buffers. This allows the decoder to use a specific dataspace for
409 //    the color aspects (e.g. because the device supports additional dataspaces, or because it wants
410 //    to perform color-space extension by inline color-space conversion to facilitate a more optimal
411 //    rendering pipeline.).
412 //
413 // Note: the size of sAspects may increase in the future by additional fields.
414 // Implementations SHOULD NOT require a certain size.
415 struct DescribeColorAspectsParams {
416     OMX_U32 nSize;                 // IN
417     OMX_VERSIONTYPE nVersion;      // IN
418     OMX_U32 nPortIndex;            // IN
419     OMX_BOOL bRequestingDataSpace; // IN
420     OMX_BOOL bDataSpaceChanged;    // IN
421     OMX_U32 nPixelFormat;          // IN
422     OMX_U32 nDataSpace;            // OUT
423     ColorAspects sAspects;         // IN/OUT
424 };
425 
426 // HDR color description parameters.
427 // This is passed via OMX_SetConfig or OMX_GetConfig to video encoders and decoders when the
428 // 'OMX.google.android.index.describeHDRColorInfo' extension is given and an HDR stream
429 // is detected.  Component SHALL behave as described below if it supports this extension.
430 //
431 // Currently, only Static Metadata Descriptor Type 1 support is required.
432 //
433 // VIDEO ENCODERS: the framework uses OMX_SetConfig to specify the HDR static information of the
434 // coded video.
435 // This may happen:
436 //   a) before the component transitions to idle state
437 //   b) before the input frame is sent via OMX_EmptyThisBuffer in executing state
438 //   c) during execution, just before an input frame with a different HDR static
439 //      information is sent.
440 //
441 // The framework also uses OMX_GetConfig to
442 //   d) verify the HDR static information that will be written to the stream.
443 //
444 // 1. Encoders SHOULD maintain an internal HDR static info data, initialized to Unspecified values.
445 //    This represents the values that will be written into the bitstream.
446 // 2. Upon OMX_SetConfig, they SHOULD update their internal state to the info received
447 //    (including Unspecified values). For specific parameters that are not supported by the
448 //    codec standard, encoders SHOULD substitute Unspecified values. NOTE: no other substitution
449 //    is allowed.
450 // 3. OMX_GetConfig SHALL return the internal state (values that will be written).
451 // 4. OMX_SetConfig SHALL always succeed before receiving the first frame if the encoder is
452 //    configured into an HDR compatible profile. It MAY fail with OMX_ErrorUnsupportedSettings error
453 //    code if it is not configured into such a profile, OR if the configured values would change
454 //    AND the component does not support updating the HDR static information mid-stream. If the
455 //    component supports updating a portion of the information, those values should be updated in
456 //    the internal state, and OMX_SetConfig SHALL succeed. Otherwise, the internal state SHALL
457 //    remain intact.
458 //
459 // VIDEO DECODERS: the framework uses OMX_SetConfig to specify the default HDR static information
460 // to use for the video.
461 //   a) This only happens if the client supplies this information, in which case it occurs before
462 //      the component transitions to idle state.
463 //   b) This may also happen subsequently if the default HDR static information changes.
464 //
465 // The framework also uses OMX_GetConfig to
466 //   c) get the final HDR static information reported by the coded bitstream after taking the
467 //      default values into account.
468 //
469 // 1. Decoders should maintain two HDR static information structures - the default values as
470 //    reported by the framework, and the coded values as reported by the bitstream - as each
471 //    structure can change independently from the other.
472 // 2. Upon OMX_SetConfig, it SHALL update its default structure regardless of whether such static
473 //    parameters could be supplied by the component bitstream. (E.g. it should blindly support all
474 //    parameter values, even seemingly illegal ones). This SHALL always succeed.
475 //  Note: The descriptor ID used in sInfo may change in subsequent calls. (although for now only
476 //    Type 1 support is required.)
477 // 3. Upon OMX_GetConfig, the component SHALL return the final HDR static information by replacing
478 //    Unspecified coded values with the default values. This SHALL always succeed. This may be
479 //    provided using any supported descriptor ID (currently only Type 1) with the goal of expressing
480 //    the most of the available static information.
481 // 4. Whenever the component processes HDR static information in the bitstream even ones with
482 //    Unspecified parameters, it SHOULD update its internal coded structure with that information
483 //    just before the frame with the new information would be outputted, and the component SHALL
484 //    signal an OMX_EventPortSettingsChanged event with data2 set to the extension index.
485 // NOTE: Component SHOULD NOT signal a separate event purely for HDR static info change, if it
486 //    occurs together with a port definition (e.g. size), color aspect or crop change.
487 // 5. If certain parameters of the HDR static information encountered in the bitstream cannot be
488 //    represented using sInfo, the component SHALL use the closest representation.
489 //
490 // Note: the size of sInfo may increase in the future by supporting additional descriptor types.
491 // Implementations SHOULD NOT require a certain size.
492 struct DescribeHDRStaticInfoParams {
493     OMX_U32 nSize;                 // IN
494     OMX_VERSIONTYPE nVersion;      // IN
495     OMX_U32 nPortIndex;            // IN
496     HDRStaticInfo sInfo;           // IN/OUT
497 };
498 
499 }  // namespace android
500 
501 extern android::OMXPluginBase *createOMXPlugin();
502 
503 #endif  // HARDWARE_API_H_
504