[vlc-devel] Severe A/V asynchronous with hardware acceleration on android
martin at martin.st
Fri May 4 11:57:42 CEST 2012
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
>> I Didn't had time yet to dig what's going one.
>> This is a regression caused by
>> 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).
More information about the vlc-devel