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

Martin Storsjö martin at martin.st
Tue Jul 1 15:35:49 CEST 2014

On Tue, 1 Jul 2014, Thomas Guillem wrote:

> 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.

Ok, good. With this check removed, it almost works for me on the Galaxy 
S3, I do get frames displayed occasionally, but most of them seem to be 
skipped, and the log displays something like this:
W/VLC     (26866): core video output: picture is too late to be displayed 
(missing 3084 ms)

The log messages come at a much slower pace than normal, indicating that 
the frame throughput for some reason is very slow.

>> 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.

I see. Ok, if the OMX_GetParameter call can give us the right format for 
most cases, it's at least a little less hopeless/fragile.

>> 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)

Sounds good; once more of these are taken care of (plus the weirdly low 
framerate when I now got it working on Galaxy S3) I can try to have a 
closer look at it.

// Martin

More information about the vlc-devel mailing list