libstagefright - Experimental hardware video decoding builds
Let's try to recap...
(2013-02-23, 16:12)Herman.Chen Wrote: RK3066 has rga to do YUV -> RGB conversion. It has a very good performance and easy interface.
I'm a bit lost. Then why did you say color conversion YUV420 -> RGB induced reduced performance? Does that happen in CPU memory?

(2013-02-23, 16:12)Herman.Chen Wrote: 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.
So, it is not possible to use private path and kHardwareCodecsOnly, right? Or can we still get a tVPU_FRAME via MediaBuffer::data() if we don't specify a native window?

(2013-02-23, 16:12)Herman.Chen Wrote: 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.
Would you mind publishing the diff on SoftwareRenderer.cpp, too?


Messages In This Thread
RE: libstagefright - Experimental hardware video decoding builds - by Koying - 2013-02-23, 18:17
libstagefright - by mo123 - 2013-05-14, 14:29
RE: libstagefright - by Koying - 2013-05-14, 14:30
RE: libstagefright - by Maverick5269 - 2013-05-16, 23:04
RE: libstagefright - by matander - 2013-05-19, 18:26
RE: libstagefright - by FreeFrag - 2013-05-22, 13:02
Logout Mark Read Team Forum Stats Members Help
libstagefright - Experimental hardware video decoding builds10