[vlc-devel] [RFC PATCH 00/11] OMX: enable android hardware buffers (zero copy)

[Thomas Guillem]

2014-07-01 12:44 GMT+02:00 Martin Storsjö <martin at martin.st>:
> On Tue, 24 Jun 2014, Thomas Guillem wrote:
>
>> I did the development on a Nexus 10 with last android 4.4.3, and I have a
>> performance issue using HW buffers. I need to investigate more since I
>> know
>> that I don't have any performances issue with my other player. I also
>> tested it
>> on a RK30 and a QCOM device.
>
>
> What QCOM device did you test it on (and on what firmware)?

Oh I got confused with my devices. I confirm that there is a
mediaserver crash on QCOM. I don't have it with Archos Video Player,
so I should be able to fix it.

>
> I've tried to test this code on a number of different devices and haven't
> gotten it working properly of any of them.
>
> On a Galaxy S3 running 4.3, I've got it almost working - I get the first
> frame displayed, then I get the following errors:
> E/VLC     (19825): iomx decoder: omx buffer should be filled at that point
> D/VLC     (19825): iomx decoder: error during decoding
> (and the last message repeated for every packet)

The "omx buffer should be filled at that point" is an extra check from me.
At that point of the code, we are necessarily using hwbuff and the
buffer is returned from OMX_FillBufferDone.
I thought nFillenLen should be always > 0 here, I was wrong (at least
for hwbuff case).
I should remove that extra check.

>
> For this device, I had to do an extra workaround for setting the hal pixel
> format for the hw buffers. This was what I had run into when I tried doing
> this myself earlier, when I concluded this to be too hacky to be worth
> pursuing. (I'll follow up with the details of this in the review of the
> actual patch for omxil.cpp.)

Indeed, for Exynos 3, we have to force the color to 0x105/0x101.

On Archos Video Player, I have a table of hal_format in function of
all the different SOC.
As I did the things a little cleaner for VLC, I found out that I was
able to get the soc hal_format by calling OMX_GetParameter() after the
enableGraphicBuffer() call. I did the test on RK30, OMAP4, and Exynos5
(Nexus 10), and I was happy to see that OMX returned me the good soc
hal_format.
But unfortunately, it's not working for Exynos 3 (Samsung S3), so I
guess there are some others SOC that won't return the good hal_format.

>
> On a Galaxy Nexus currently on 4.1, I get the following errors:
> D/VLC     ( 1388): iomx decoder: OMX_SetParameter failed (80001001 :
> OMX_ErrorUndefined)
> E/VLC     ( 1388): iomx decoder: HwBuffer_AllocateBuffers(1) failed
> E/VLC     ( 1388): iomx decoder: AllocateBuffer failed (80001000 :
> OMX_ErrorInsufficientResources)
> D/VLC     ( 1388): iomx decoder: OMX_AllocateBuffers failed (80001000, 1)
> D/VLC     ( 1388): iomx decoder: PortReconfigure(1)::done
> D/VLC     ( 1388): iomx decoder: PortReconfigure failed
> D/VLC     ( 1388): iomx decoder: error during decoding

For OMAP4, I have the same crash as you during PortReconfigure (but
the hal_format is good), I don't have it on Archos Video Player.

>
> And on a Galaxy S4 (running 4.4) and Nexus 4 (running 4.3 currently), the
> mediaserver crashes.
>
> There's no important user data on neither of the nexus devices, so I can
> flash them to other factory images if necessary to test.
>
>
> So the Galaxy S3 case seems to be the one closest to working - I'll have a
> closer look later to see if I can figure out what's going wrong in the code,
> unless you happen to find the issue yourself before.

I was too confident, there are sill some issues and works to be done
with that last patch:

 - Fix PortReconfigure on OMAP4
 - Fix mediaserver crash on QCOM (S4, Nexus 4, Nexus 7 v2)
 - Fix perf/timing issue on Exynos5 and Exynos4 (and probably all others)
 - Don't crash and do fallback to next codec or OMX without direct
rendering in case buffers can't be allocated with returned hal_format.
 - table of hal_format function of the SOC ? (maybe not useful as
MediaCodec should work for devices that don't give a good hal_format)

>
>
> // Martin
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel

-- 


This email and any files transmitted with it are confidential and are 
intended solely for the use of the individual or entity to which they are 
addressed. Access to this e-mail by anyone else is unauthorised. If you are 
not the intended recipient, any disclosure, copying, distribution or any 
action taken or omitted to be taken in reliance on it, is prohibited. 
E-mail messages are not necessarily secure. Archos does not accept 
responsibility for any changes made to this message after it was sent.