2013-02-23, 16:12
(2013-02-23, 11:09)fun_ Wrote:(2013-02-23, 10:51)Herman.Chen Wrote: There is an error when OMX component create GraphicBuffer from NativeWindow, NativeWindow width and height are not set correctly. We fix the bug and send the libstagefright.so below. Please download and check whether can play 1080p normally.
libstagefright.so
this libstagefright.so is for both 4.0 and 4.1?
does RK2918 have same hardware decoder and same bug?
This libstagefright.so is for 4.1, not for 4.0.
RK2918 uses different GPU, do not have the same bug. This bug is caused by GPU limit not hardware decoder.
(2013-02-23, 11:26)fun_ Wrote: can you provide vpu_global.h or "typedef struct tVPU_FRAME { ... } VPU_FRAME;" part under free/open source license?
I can see it in hardware/rk29/libon2/ in RK's ICS source, but license is not clear.
EDIT: ah, sorry, it also exists in your libvpu.tar. but license is not clear too...
----
btw, I'm not sure this kind of device specific hack can be merged to XBMC. koying?
VPU_FRAME part structure is writen by Rockchip. It has no specified license. We decide to open it, but we do not add license on it so far.
VPU_FRAME structure is a private path, and it is a hack for andrdoid framework and our hardware combination. In my opinion as a SW engineer it is not very good for a general software. I know this private path is quite ugly but it works.
(2013-02-23, 12:43)Koying Wrote: The good news is that your updated libstagefright.so prevents the vpu from crashing
The bad news is that performance is very poor above 720p
Doesn't the rk3066 have HW YUV -> RGB conversion?
We indeed use kHardwareCodecsOnly to indicate that we only wants HW accelerated codecs. I don't think setting this flag should influence the way the frame is rendered, though.
On other platforms, if you don't supply an ANativeWindow to OMXCodec::Create, the buffers are created inside libstagefright rather than using the ones of the surface. You then get access to the frame content via MediaBuffer::data() rather than MediaBuffer::graphicbuffer(). Those have to be in the origin color system, e.g. yuv420, which might solve the color conversion performance issue as we are using GL shaders to blit the YUV content.
Does your SoftwareRenderer patch means you're returning a opaque struct rather than the actual yuv data?
Glad to hear the lib can help to resolve your problem.
RK3066 has rga to do YUV -> RGB conversion. It has a very good performance and easy interface.
Both kHardwareCodecsOnly and kSoftwareCodecsOnly use HW to decode video, but the difference is in the output. One is standard MediaBuffer with GraphicBuffer (in 4.1), The other is in for private path to direct render to FB which can make 1080p more smooth.
MediaBuffer::data() is for 4.0 and MediaBuffer::graphicbuffer() first appear in 4.1 for more direct connect between surface and decoder.
Yes, you are right. SoftwareRenderer patch indeed skip the color conversion and direct use hwc to composite yuv data to FB. The opaque struct contains the phycial address of video frame and some other information to make it possible to do the direct blending.Finally it comes to a zero copy. The early version of Samsung code use similiar strategy.
