I am working with the Bellagio implementation of openMAX. I see many variations from openMAX spec. For eg:
1. The nBufferSize field of OMX_PORTDEFINITIONTYPE is used to specify the min buffer size that must be allocated/used for a port in component. So this is specific to a component and should not be altered by the client by OMX_SetParameter(). Also OMX_AllocateBuffer()/UseBuffer() should check whether allocated/used buffer is greater than nBufferSize . This is not happening in Bellagio.
Note: The OpenMAX IL spec 1.1 spec(page 74) clearly mentions that nBufferSize specifies the minimum size in bytes for buffers ( in all cases) that are allocated for this port. For e.g a codec can have a minimum frame length which is needed for decoding/encoding, and may expect each OMAX buffers to have atleast one frame. In this case nBufferSize represent the frame length.
2. In tunnelling the buffer size of the port is assumed to be nBufferSize, which is not right.
As mentioned above nBuffersize field indicate the min buffersize requirement of the port. The client should have the flexibility to specify the a buffer size greater than this value (similar to Allocate Buffer in non-tunnelling). Otherwise we r severely restricting the flexibility of the framework.
One way is to allow for the updation of nBufferSize field of the port by SetParameter() in case of Tunneling only (currently done in Bellagio) , but this is inconsistent with the OMAX IL spec definition of port. We can propose to add this special case in the IL spec.
Hope these issues will be taken care in the next release.
3. Bellagio implementation require two threads per component, which may not fit into many current mobile multimedia architecture.
For eg: In our system, we can have maximum 256 threads, and most of which are already used. So migration to Bellagio is not straight-forward with the 2 threads per components.
I think the following architectural option can also be explored for the Bellagio framework to make it more robust & flexible.
1. w.r.t command handling, we can execute the command in the client context also. So client should be given the flexibility to chose between the two different command handling mechanisms ( separate thread for command OR command handling in client thread itself).
2. Exploring the implementation of passive components, i.e components without any thread for buffer handling; buffer handling happen in the context of other active components. This make sense for post processing components.
Also the sample components provided with Bellagio are not passing some of the OpenMax IL conformance tests published by khronos, I don't know whether the problem is with the Bellagio framework or the conformance suite. Let me know if u have more info on this .
Regards
Jerry Mannil
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Jerry,
I agree with you that a correct check of the minimum buffer size in the AllocateBuffer/UseBuffer function is missing. I'll add this bug to the bug list, and it will be solved in the next release.
Regarding the tunneling case, I consider that the user, in general, is not allowed to establish the size of the buffer in a tunnel. In fact it is a responsibility of the component that has been chosen as buffer supplier. It should check if the tunneled component accept a given size, but in any case it is the supplier component that decides the size of buffers. If a component wants to allow the application to chose the size of the tunnel buffer, a custom parameter can be added.
Regarding the huge numbers of threads, the solution adopted in Bellagio has been reached after several approches to support the full interop profile for the components. One message handler for each compoent avoids possible deadlocks due to the tunneling. the buffer handler allows the user requests to be asynchronous. In a embedded platform context probably the buffer handling thread can be replaced with an accelerated device.
Regarding the test framework, as far as I know the components pass all the conformance tests, even if we didn't go through the official process, so I can't say that we are conformant. It will be interesting to know why in your case some tests fail? can you tell me which test?
Regards,
Giulio
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Base profile is passing for all standarad Bellagio component.
For Interop profile the following test cases are failing
1. ResourcePreemptionTest
2. WaitForResourcesTest
3. PortDisableEnableTest ( running this test cause seg fault)
This behaviour is seen for all standarad bellagio components ( volume, Ogg vorbis, etc )
Also in the component, the cleanup is not done properly if constructor fails. The private structure is not freed, when constructor fails. This may cause memory leaks !!!.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Bellagio component doesn't support resoure management yet. So resource preemption and wait for resource test are failing.
As far as PDET is concerned there is some issue with the test implementation and that is a known bug in the conformance test. Hope in IL 1.1.1 the issue will be resolved.
I'm not sure but think it's not the right forum to discuss details about the conformance test issues since it's not free.
We will resolve other bug very soon. Keep it up.
Thanks,
Pankaj
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
hi all,
I am working with the Bellagio implementation of openMAX. I see many variations from openMAX spec. For eg:
1. The nBufferSize field of OMX_PORTDEFINITIONTYPE is used to specify the min buffer size that must be allocated/used for a port in component. So this is specific to a component and should not be altered by the client by OMX_SetParameter(). Also OMX_AllocateBuffer()/UseBuffer() should check whether allocated/used buffer is greater than nBufferSize . This is not happening in Bellagio.
Note: The OpenMAX IL spec 1.1 spec(page 74) clearly mentions that nBufferSize specifies the minimum size in bytes for buffers ( in all cases) that are allocated for this port. For e.g a codec can have a minimum frame length which is needed for decoding/encoding, and may expect each OMAX buffers to have atleast one frame. In this case nBufferSize represent the frame length.
2. In tunnelling the buffer size of the port is assumed to be nBufferSize, which is not right.
As mentioned above nBuffersize field indicate the min buffersize requirement of the port. The client should have the flexibility to specify the a buffer size greater than this value (similar to Allocate Buffer in non-tunnelling). Otherwise we r severely restricting the flexibility of the framework.
One way is to allow for the updation of nBufferSize field of the port by SetParameter() in case of Tunneling only (currently done in Bellagio) , but this is inconsistent with the OMAX IL spec definition of port. We can propose to add this special case in the IL spec.
Hope these issues will be taken care in the next release.
3. Bellagio implementation require two threads per component, which may not fit into many current mobile multimedia architecture.
For eg: In our system, we can have maximum 256 threads, and most of which are already used. So migration to Bellagio is not straight-forward with the 2 threads per components.
I think the following architectural option can also be explored for the Bellagio framework to make it more robust & flexible.
1. w.r.t command handling, we can execute the command in the client context also. So client should be given the flexibility to chose between the two different command handling mechanisms ( separate thread for command OR command handling in client thread itself).
2. Exploring the implementation of passive components, i.e components without any thread for buffer handling; buffer handling happen in the context of other active components. This make sense for post processing components.
Also the sample components provided with Bellagio are not passing some of the OpenMax IL conformance tests published by khronos, I don't know whether the problem is with the Bellagio framework or the conformance suite. Let me know if u have more info on this .
Regards
Jerry Mannil
Hi Jerry,
I agree with you that a correct check of the minimum buffer size in the AllocateBuffer/UseBuffer function is missing. I'll add this bug to the bug list, and it will be solved in the next release.
Regarding the tunneling case, I consider that the user, in general, is not allowed to establish the size of the buffer in a tunnel. In fact it is a responsibility of the component that has been chosen as buffer supplier. It should check if the tunneled component accept a given size, but in any case it is the supplier component that decides the size of buffers. If a component wants to allow the application to chose the size of the tunnel buffer, a custom parameter can be added.
Regarding the huge numbers of threads, the solution adopted in Bellagio has been reached after several approches to support the full interop profile for the components. One message handler for each compoent avoids possible deadlocks due to the tunneling. the buffer handler allows the user requests to be asynchronous. In a embedded platform context probably the buffer handling thread can be replaced with an accelerated device.
Regarding the test framework, as far as I know the components pass all the conformance tests, even if we didn't go through the official process, so I can't say that we are conformant. It will be interesting to know why in your case some tests fail? can you tell me which test?
Regards,
Giulio
Hi Giulio ,
Base profile is passing for all standarad Bellagio component.
For Interop profile the following test cases are failing
1. ResourcePreemptionTest
2. WaitForResourcesTest
3. PortDisableEnableTest ( running this test cause seg fault)
This behaviour is seen for all standarad bellagio components ( volume, Ogg vorbis, etc )
Also in the component, the cleanup is not done properly if constructor fails. The private structure is not freed, when constructor fails. This may cause memory leaks !!!.
Hi Jerry,
Bellagio component doesn't support resoure management yet. So resource preemption and wait for resource test are failing.
As far as PDET is concerned there is some issue with the test implementation and that is a known bug in the conformance test. Hope in IL 1.1.1 the issue will be resolved.
I'm not sure but think it's not the right forum to discuss details about the conformance test issues since it's not free.
We will resolve other bug very soon. Keep it up.
Thanks,
Pankaj