[Bug 761611] New: Android (hardware accelerated) playback doesn't recover well if decoding gets too late (pile up of frame drop)

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=761611

            Bug ID: 761611
           Summary: Android (hardware accelerated) playback doesn't
                    recover well if decoding gets too late (pile up of
                    frame drop)
    Classification: Platform
           Product: GStreamer
           Version: 1.7.1
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: gregoire at gentil.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

OS: Android 6.0.1

Device: Nexus 7 2013 and Nexus 5x

Gstreamer version: 1.7.2 (> to commits of
https://bugzilla.gnome.org/show_bug.cgi?id=761014)

Video test case: http://www.gentil.com/tmp/video.zip

Application: Tutorial 5 (cgit.freedesktop.org/~slomo/gst-sdk-tutorials/)

Pipeline: playbin (zero copy from hardware acceleration to glimagesink)


WORKING: The video provided here (http://www.gentil.com/tmp/video.zip) works
perfectly well on Nexus 5x.

NOT WORKING: The same video has some trouble on Nexus 5x at mark 31 seconds.
For some reasons, the stream gets jerky (perhaps because a frame header is not
correct in the video) and the player piles up warnings:

02-05 14:02:53.096: W/GStreamer+amcvideodec(32083): 0:04:19.649383547
0xa050be90
gstamcvideodec.c:1307:gst_amc_video_dec_loop:<amcvideodec-omxqcomvideodecoderavc0>
Frame is too late, dropping (deadline -0:00:00.003625245)
02-05 14:02:53.140: W/GStreamer+amcvideodec(32083): 0:04:19.694061280
0xa050be90
gstamcvideodec.c:1307:gst_amc_video_dec_loop:<amcvideodec-omxqcomvideodecoderavc0>
Frame is too late, dropping (deadline -0:00:00.013943115)

The problem is that there is no kind of recovery. In other words, it seems that
if some hardware accelerated frame callbacks are missing, everything goes
wrong, worse and worse and worse. Gstreamer doesn't try to "recover" and catch
the next hardware decoding callback. It just piles up the drop frames over and
over.

The same video with the exact same tutorial-5 binaries work fine on a more
powerful device such as Nexus 5x. Most likely, the Nexus 5x is powerful enough
to go over the glitch at the 31-second mark and there is no callback missing.


Remark: You need to play the video on nexus 7 2013 entirely : wait for the
31-second mark to see the problem.

Also, if you let the video plays entirely and replays it by pressing the play
button (without selecting another video), the stream is completely jerky with a
lot of warning messages. But if you reselect the video with the "select a file"
button, the video plays well at least for the first 30 seconds.

In other words, gstreamer seems to remind of all the drop frames and still
doesn't manage to recover even if the video is played from the beginning again.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.