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

[Thomas Guillem]

I'm almost sure that the low framerate you got on Galaxy S3 is the
same I have on Nexus 10 (Exynos 4 vs Exynos 5).
But it's a little less visible on Nexus 10, I have between 0 and 5
frames dropped per seconds.

Thanks for looking it up, I'll continue my work then.

2014-07-01 15:35 GMT+02:00 Martin Storsjö <martin at martin.st>:
> 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
> _______________________________________________
> 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.