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

[XilasZ]

> 05-08 22:29:08.810: E/VLC(18445): ES_OUT_SET_(GROUP_)PCR  is called too
> late (pts_delay increased to 1500 ms)
> 05-08 22:29:08.810: E/VLC(18445): ES_OUT_RESET_PCR called
> 05-08 22:29:08.830: W/VLC(18445): early picture skipped
> 05-08 22:29:08.870: D/VLC(18445): flushing
> 05-08 22:29:08.870: D/VLC(18445): End of audio preroll
> 05-08 22:29:08.880: D/VLC(18445): OmxEventHandler (OMX_EventCmdComplete,
> OMX_CommandFlush, 0)
> 05-08 22:29:08.900: D/VLC(18445): Buffering 0%
> 05-08 22:29:08.900: D/VLC(18445): Buffering 21%
> 05-08 22:29:08.900: D/VLC(18445): Buffering 43%
> 05-08 22:29:08.910: D/VLC(18445): Buffering 66%
> 05-08 22:29:08.930: D/VLC(18445): Buffering 88%
> 05-08 22:29:08.930: D/VLC(18445): Stream buffering done (1640 ms in 33 ms)
> 05-08 22:29:09.240: D/VLC(18445): Decoder buffering done in 305 ms
> 05-08 22:29:10.050: D/VLC(18445): End of video preroll
>

After adding an option to select the audio output yesterday, and testing
all 3 aouts, i noticed that this "glitch" (which  happens with or without
HW decoding) is caused by the native AudioTrack output.

With the java AudioTrack output, my 720p files play fine with both HW and
SW decoding.

As remi said, desync can still happens, since it's not yet handled in
android audio outputs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20120510/b008a0d3/attachment.html>