[Herman.Chen]

I'm a bit lost. Then why did you say color conversion YUV420 -> RGB induced reduced performance? Does that happen in CPU memory?

Color conversion itself will not reduce performance and it is necessary. But the problem is the OMX component's color conversion RGB destination is surface buffer not final FB, GPU still have to blit it to final FB. Use private path the yuv data will be blit directly to final FB. And more color conversion and GPU rendering must be serially executed which will reduce performance.

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?

Yes, you're right. In kHardwareCodecsOnly case the video frame data is output in the MediaBuffer::GraphicBuffer. In kSoftwareCodecsOnly case will output a tVPU_FRAME via MediaBUffer::data() it is not depend on the native window.

Would you mind publishing the diff on SoftwareRenderer.cpp, too?

No, I don't mind personally. But I am not sure.I have to check when I return to work on Monday.

is decoded frame always converted and composed to RGB framebuffer in zero copy path?

I think most stick/STB products with RK3066 use 1280x720 framebuffer. then, any 1080p videos are downscaled to 720p for framebuffer, and lastly upscaled to 1080p for 1080p TV?

or 1920x1080 YUV framebuffer can be overlayed on top of 1280x720 RGB(UI) framebuffer?

(this question will be off-topic, but I want to know how "normal video player apps" works on RK3066 because I want to know difference between other apps and XBMC...)

For most device we use 720p FB. But on HW we can use a overlay output for 1920x1080p YUV I don't know much about the final product's choice. They have to balance more things.

Hmm there is a issue Chen a AVC Blu-Ray stream .m2ts shows strange frame jumping (reorder issue) in the beginning for around 35 seconds either with H/W+ or XBMC
no frame jumps with the kSoftwareCodecsOnly path (RKPlayer,MX Player Hardware Mode, Archos Video Player). Maybe it's a parser issue i guess both player use in these modes the libav parser not yours.
Though it happens only on the first load seeking back doesn't show these frame jumps anymore.

Mpeg-2 Blu-Ray stream .m2ts still fallsback to ff-mpeg2video, is the vpu mpeg-2 decoder not accessible via libstagefright as neither mx player can use it in H/W+ mode ?

Also .m2ts and .mkv VC-1 fallback to ff-vc1

so currently only H.264 seems to work accelerated for RK3066, which at least grants most web based plugin support by now

tested and work now

Vimeo 1080p
Youtube 1080p
Apple Quicktime Trailer 1080p

Lot of Apple Quicktime 1080p content tough wont work sufficient yet, especially Game content Promo Videos that use very high framerates

so most H.264 based Web Platforms should work now

Mpeg-4 Part 2 ASP 1080p 23.976 stf-mpeg4 also works though frame drop issues

About the ts stream problem ts stream usually has a very high bitrate and ts parsing will consume a lot CPU and have a heavy load on file system specially on flash base storage. The first load will have a lot cache miss both on code and file reading so it is relatively slow, the second run will be better. It is normal.

vpu mpeg-2 decoder can decode mpeg2 stream. Maybe it is a config or parameter issue? I will check with my colleague. I am not sure whether mpeg2 and ts omx component is tested completely.

I have checked it with my colleague. vpu mpeg-2 deocder can not support OMX component so far due to parser stream and timestamp problem. We will fix this bug on later version.