Khronos Public Bugzilla
Bug 134 - Bug: get_parameter for OMX_VIDEO_PARAM_PORTFORMATTYPE
Bug: get_parameter for OMX_VIDEO_PARAM_PORTFORMATTYPE
Status: NEW
Product: OpenMAX-IL
Classification: Unclassified
Component: Specification
1.1.2
All All
: P2 major
: ---
Assigned To: Frederic Gabin
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-10 18:10 PDT by jdong
Modified: 2009-04-10 18:10 PDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jdong 2009-04-10 18:10:42 PDT
section 4.3.5, quote,

OMX_VIDEO_PARAM_PORTFORMATTYPE is the structure for the port format parameter. It enumerates the various data input/output formats supported by the port.
OMX_VIDEO_PARAM_PORTFORMATTYPE can be used with both OMX_GetParameter and OMX_SetParameter. In the OMX_GetParameter case, the caller specifies all fields and the OMX_GetParameter call returns the value of eFormat. The value of nIndex is the range 0 to N-1, where N is the number of formats supported by the port. There is no need for the port to report N, as the caller can determine N by enumerating all the formats supported by the port. Each port shall support at least one format. If there are no more formats, OMX_GetParameter returns OMX_ErrorNoMore (i.e., nIndex is supplied where the value is N or greater). Ports supply formats in order of preference, which means that higher preference formats are provided with lower values of nIndex.

The description is not correct in that:
1. Why does the caller needs to specify all the fields of this structure?
   It appears that the following fields should be enough:
   OMX_U32 nSize;
   OMX_VERSIONTYPE nVersion;
   OMX_U32 nPortIndex;
   OMX_U32 nIndex;
2. There is no field called "eFormat"; "eColorFormat" and "eCompressionFormat" may be used instead?

3. The sample/reference component implementation from the website:
http://www.khronos.org/openmax/sample_implementation/OMX_CONF_MyComponent_Alt.c
is also not correct.
In the implementation, it overwrites the fields supplied by the caller

4. Lastly, i noticed that in the tables later in the spec, only two fields are marked as "write" access: "eColorFormat" and "eCompressionFormat". This should be consistent with the description here (in other words, the spec should say that only these two fields needs to be updated by the callee).

5. Not sure about how the spec does with the last field in this structure: xFramerate. It appears this field should also be updated by the callee? if so, then the related tables in the spec and the above description should be modified.

thanks.