[vlc-devel] Severe A/V asynchronous with hardware acceleration on android

[Martin Storsjö]

On Fri, 4 May 2012, Martin Storsjö wrote:

> On Fri, 4 May 2012, XilasZ wrote:
>
>> I get the same thing on the HTC OneX (same cpu as you, Tegra3),
>> plus a weird image doubling, as if the chroma planes are shifted
>> vertically compared to the luma plane.
>> And as if that wasn't enough, when enabled, HW decoding consume
>> more cpu than SW on the OneX.
>> So i think we can say HW decoding is not supported yet on Tegra3
>> :p
>> 
>> I Didn't had time yet to dig what's going one.
>> 
>> This is a regression caused by
>> cd0112a5467a01073964e1d1e6d43caf044aacf2.
>> I don't know if  the issue occurs on other devices, at least I revert
>> the change and fix it on my TF201.
>> 
>> 
>> Interesting, i'll test hw decoding on my htc desire (snapdragon chip from
>> qualcomm), see if it happens.
>
> Hmm, this works on the devices I've tested lately.
>
> Can you have a look at what goes wrong when this is enabled, i.e., is the 
> data returned by OMX_IndexConfigCommonOutputCrop bad, or is it good initially 
> but bad when re-reading it after the OMX_EventPortSettingsChanged event that 
> indicated an updated crop rect? (Since this particular commit only makes us 
> re-read the same data that has been read before, when the decoder indicates 
> that it might have changed.)

That is, info which is useful for debugging this is:

- All the parameters used in GetPortDefinition, nFrameWidth/nFrameHeight, 
nStride, nSliceHeight, and crop_rect width/height (and top value - this 
should only match the TI specific pixel formats, I do hope tegra doesn't 
use the same privately allocated pixel formats as TI!), their values at 
each GetPortDefinition invocation (startup, after port reconfigure, after 
crop rect settingschanged event).

// Martin