libstagefright - Experimental hardware video decoding builds
(2013-02-23, 10:51)Herman.Chen Wrote:
(2013-02-23, 05:43)Koying Wrote: Hi Herman,

Thanks for joining the thread.

We are passing a native windows to OMXCodec::Create, so rendering is done entirely inside libstagefright and we don't have any way to correct the frame size.

Related to this, it looks like the frame size passed in the metadata after a read is not correct, I. E. Is not mod16/mod32 but the published one.

Could it be that solving the metadata bug would also solve the rendering bug?
The OMXCodec::Create has a flags argument, we mainly use two type:
kSoftwareCodecsOnly = 8,
kHardwareCodecsOnly = 16,
If kHardwareCodecsOnly is used OMX component will convert video frame from yuv to RGBA and copy to GraphicBuffer which is allocated from NativeWindow. The disavantage is that the colour conversion consumes bandwidth and the conversion and display are working serially.
If kSoftwareCodecsOnly is used OMX component will output a private VPU_FRAME structure and use SoftwareRender to direct display YUV frame on framebuffer by hwc.
Both of these two path have a limitation on NativeWindow, the NativeWindow buffer width has to be 32 aligned height has to be 16 aligned by native_window_set_buffers_geometry. Then use crop function native_window_set_crop to display correctly.

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 below. Please download and check whether can play 1080p normally.
The good news is that your updated prevents the vpu from crashing Smile
The bad news is that performance is very poor above 720p Sad
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?

Messages In This Thread
RE: libstagefright - Experimental hardware video decoding builds - by Koying - 2013-02-23, 12:43
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
This forum uses Lukasz Tkacz MyBB addons.