blob: 6c1ba3de00270a552988f334617f7364fa7b09f9 [file] [log] [blame]
James Dong334de522012-03-12 12:47:14 -07001/*
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
Andreas Huber00e595f2013-06-25 10:08:42 -070021#include <media/hardware/OMXPluginBase.h>
22#include <media/hardware/MetadataBufferType.h>
Mathias Agopian6a3c05b2017-04-27 20:06:55 -070023#include <cutils/native_handle.h>
James Dong334de522012-03-12 12:47:14 -070024#include <utils/RefBase.h>
25
Lajos Molnar7c357a72016-03-08 11:30:15 -080026#include "VideoAPI.h"
27
James Dong334de522012-03-12 12:47:14 -070028#include <OMX_Component.h>
29
Mathias Agopian6a3c05b2017-04-27 20:06:55 -070030struct ANativeWindowBuffer;
31
James Dong334de522012-03-12 12:47:14 -070032namespace android {
33
Lajos Molnard5f79352016-02-11 14:20:39 -080034// 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//
James Dong334de522012-03-12 12:47:14 -070039// 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
Lajos Molnar5f39f602013-07-17 14:55:55 -070050// 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.
Lajos Molnard5f79352016-02-11 14:20:39 -080057//
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.
James Dong334de522012-03-12 12:47:14 -070076struct EnableAndroidNativeBuffersParams {
77 OMX_U32 nSize;
78 OMX_VERSIONTYPE nVersion;
79 OMX_U32 nPortIndex;
80 OMX_BOOL enable;
81};
82
Lajos Molnard5f79352016-02-11 14:20:39 -080083typedef struct EnableAndroidNativeBuffersParams AllocateNativeHandleParams;
84
Lajos Molnar9f590df2015-05-15 20:31:57 -070085// 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.
James Dong334de522012-03-12 12:47:14 -070088//
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
Lajos Molnar9f590df2015-05-15 20:31:57 -070095// interpret the meta data is outside of the scope of this parameter.
James Dong334de522012-03-12 12:47:14 -070096//
Lajos Molnar9f590df2015-05-15 20:31:57 -070097// 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.
Lajos Molnar5f39f602013-07-17 14:55:55 -0700100//
Lajos Molnar9f590df2015-05-15 20:31:57 -0700101// 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.
Lajos Molnar5f39f602013-07-17 14:55:55 -0700106//
Lajos Molnar9f590df2015-05-15 20:31:57 -0700107// 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.
James Dong334de522012-03-12 12:47:14 -0700122struct StoreMetaDataInBuffersParams {
123 OMX_U32 nSize;
124 OMX_VERSIONTYPE nVersion;
125 OMX_U32 nPortIndex;
126 OMX_BOOL bStoreMetaData;
127};
128
Lajos Molnar07d93d12013-05-03 13:20:53 -0700129// Meta data buffer layout used to transport output frames to the decoder for
130// dynamic buffer handling.
Lajos Molnar9f590df2015-05-15 20:31:57 -0700131struct VideoGrallocMetadata {
132 MetadataBufferType eType; // must be kMetadataBufferTypeGrallocSource
Lajos Molnarabaaf702015-07-20 15:29:24 -0700133#ifdef OMX_ANDROID_COMPILE_AS_32BIT_ON_64BIT_PLATFORMS
134 OMX_PTR pHandle;
135#else
Lajos Molnard910f3c2015-06-02 19:43:16 -0700136 buffer_handle_t pHandle;
Lajos Molnarabaaf702015-07-20 15:29:24 -0700137#endif
Lajos Molnar9f590df2015-05-15 20:31:57 -0700138};
139
Lajos Molnara8c24542015-06-01 21:13:47 -0700140// Legacy name for VideoGrallocMetadata struct.
Lajos Molnard910f3c2015-06-02 19:43:16 -0700141struct VideoDecoderOutputMetaData : public VideoGrallocMetadata {};
Lajos Molnara8c24542015-06-01 21:13:47 -0700142
Lajos Molnar9f590df2015-05-15 20:31:57 -0700143struct VideoNativeMetadata {
144 MetadataBufferType eType; // must be kMetadataBufferTypeANWBuffer
Lajos Molnarabaaf702015-07-20 15:29:24 -0700145#ifdef OMX_ANDROID_COMPILE_AS_32BIT_ON_64BIT_PLATFORMS
146 OMX_PTR pBuffer;
147#else
Lajos Molnar9f590df2015-05-15 20:31:57 -0700148 struct ANativeWindowBuffer* pBuffer;
Lajos Molnarabaaf702015-07-20 15:29:24 -0700149#endif
Lajos Molnar9f590df2015-05-15 20:31:57 -0700150 int nFenceFd; // -1 if unused
Lajos Molnar07d93d12013-05-03 13:20:53 -0700151};
152
Praveen Chavan99908372016-01-13 01:32:25 -0800153// Meta data buffer layout for passing a native_handle to codec
154struct 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
Lajos Molnardde86f72013-05-03 13:22:13 -0700164// 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.
180struct 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
James Dong334de522012-03-12 12:47:14 -0700189// 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.
194struct 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.
208struct 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
Andreas Huber7682a9c2012-09-28 11:32:16 -0700221// 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.
226struct PrependSPSPPSToIDRFramesParams {
227 OMX_U32 nSize;
228 OMX_VERSIONTYPE nVersion;
229 OMX_BOOL bEnable;
230};
James Dong334de522012-03-12 12:47:14 -0700231
Lajos Molnar524077c2014-07-25 07:53:56 -0700232// 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
Lajos Molnarea5da672015-01-30 10:36:11 -0800238// 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
Lajos Molnar524077c2014-07-25 07:53:56 -0700242// corresponds to the described raw video format, and the potentially corrected
243// stride and slice-height info.
244//
Lajos Molnarea5da672015-01-30 10:36:11 -0800245// 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.
Lajos Molnar8d513b22016-01-26 18:21:25 -0800258
259// @deprecated: use DescribeColorFormat2Params
Lajos Molnar212e9162016-02-24 18:01:10 -0800260struct DescribeColorFormat2Params;
Lajos Molnar524077c2014-07-25 07:53:56 -0700261struct 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;
Lajos Molnarea5da672015-01-30 10:36:11 -0800270 OMX_BOOL bUsingNativeBuffers;
Lajos Molnar524077c2014-07-25 07:53:56 -0700271
272 // output: fill out the MediaImage fields
273 MediaImage sMediaImage;
Lajos Molnar212e9162016-02-24 18:01:10 -0800274
Chih-Hung Hsieh1bf71ef2016-09-01 11:43:58 -0700275 explicit DescribeColorFormatParams(const DescribeColorFormat2Params&); // for internal use only
Lajos Molnar524077c2014-07-25 07:53:56 -0700276};
277
Lajos Molnar8d513b22016-01-26 18:21:25 -0800278// 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.
282struct 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;
Lajos Molnar212e9162016-02-24 18:01:10 -0800295
296 void initFromV1(const DescribeColorFormatParams&); // for internal use only
Lajos Molnar8d513b22016-01-26 18:21:25 -0800297};
298
Rachad7cb0d392014-07-29 17:53:53 -0700299// 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.
311struct 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
Lajos Molnar30f54822016-03-09 09:03:46 -0800320// 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.
Lajos Molnar51de0ba2016-01-15 16:12:33 -0800324//
Lajos Molnar30f54822016-03-09 09:03:46 -0800325// bDataSpaceChanged and bRequestingDataSpace is assumed to be OMX_FALSE unless noted otherwise.
Lajos Molnar51de0ba2016-01-15 16:12:33 -0800326//
Lajos Molnar30f54822016-03-09 09:03:46 -0800327// 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:
Lajos Molnarb4e0bce2016-03-09 07:47:27 -0800365// a) before the component transitions to idle state
366// b) during execution, when the resolution or the default color aspects change.
Lajos Molnar30f54822016-03-09 09:03:46 -0800367//
368// The framework also uses OMX_GetConfig to
Lajos Molnarb4e0bce2016-03-09 07:47:27 -0800369// c) get the final color aspects reported by the coded bitstream after taking the default values
Lajos Molnar30f54822016-03-09 09:03:46 -0800370// 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
Lajos Molnarb4e0bce2016-03-09 07:47:27 -0800392// f) (optional) get guidance for the dataspace to set for given color aspects, by setting
Lajos Molnar30f54822016-03-09 09:03:46 -0800393// 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.).
Lajos Molnar51de0ba2016-01-15 16:12:33 -0800412//
Lajos Molnarb4e0bce2016-03-09 07:47:27 -0800413// Note: the size of sAspects may increase in the future by additional fields.
414// Implementations SHOULD NOT require a certain size.
Lajos Molnar56cc3742016-02-29 20:13:36 -0800415struct DescribeColorAspectsParams {
Lajos Molnar30f54822016-03-09 09:03:46 -0800416 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
Lajos Molnar51de0ba2016-01-15 16:12:33 -0800424};
425
Lajos Molnarb4e0bce2016-03-09 07:47:27 -0800426// 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.
492struct DescribeHDRStaticInfoParams {
493 OMX_U32 nSize; // IN
494 OMX_VERSIONTYPE nVersion; // IN
495 OMX_U32 nPortIndex; // IN
496 HDRStaticInfo sInfo; // IN/OUT
497};
498
James Dong334de522012-03-12 12:47:14 -0700499} // namespace android
500
501extern android::OMXPluginBase *createOMXPlugin();
502
503#endif // HARDWARE_API_H_