After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 727511 - on android using decodebin we can playback 1080p60 drops lots of frame, playback very jumpy
on android using decodebin we can playback 1080p60 drops lots of frame, playb...
Status: RESOLVED DUPLICATE of bug 731204
Product: GStreamer
Classification: Platform
Component: gst-android
1.2.3
Other All
: Normal major
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-04-02 19:48 UTC by Alok
Modified: 2014-10-08 07:36 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Alok 2014-04-02 19:48:11 UTC 
Based on Sebastian Dröge, input writing this defect.
	
When using decodebin in pipeline for 1080p60 video file, (it is using amcvideodec-omxsecavcdec0) but it is dropping lots of
frame for 1080p 60fps (hence skipping frames)
>
> 03-26 12:22:33.745: W/GStreamer+amcvideodec(4817): 0:01:01.052789946
> 0x6039b630
> gstamcvideodec.c:1158:gst_amc_video_dec_loop:<amcvideodec-omxsecavcdec0>
> Frame is too late, dropping (deadline 0:00:00.084564417)
> 03-26 12:22:33.745: W/GStreamer+amcvideodec(4817): 0:01:01.054200696
> 0x6039b630
> gstamcvideodec.c:1158:gst_amc_video_dec_loop:<amcvideodec-omxsecavcdec0>
> Frame is too late, dropping (deadline 0:00:00.067775529)
>
> pipeline as "filesrc ! decodebin ! eglglessink", should adding queue buffer
> will help ?

This is most likely a problem of amcvideodec and eglglessink not doing
zerocopy rendering together. Could you file a feature request bug about
that at http://bugzilla.gnome.org ?

full logs below.

http://pastebin.com/zp5PQMMN
Comment 1 Alok 2014-04-02 19:49:21 UTC 
1080p60 drops lots of frame. We are very interested to get 1080p60 playback smooth.
Comment 2 Nicolas Dufresne (ndufresne) 2014-04-02 20:25:16 UTC 
Could you provide a bit more detail about the device you are running on. Not stating this is device specific, but it may help when someone try to handle this case.

At least it seems to not use the Google SW decoder, (amcvideodec-omxsecavcdec0) meaning OMX.SEC.avc codec being used. Would be nice to make sure this component is really HW accelerated before digging into EGL zerocopy stuff when testing on this platform.

Adding a trace with some caps could help too, e.g. *CAPS*:7. The amc debug does not seem to be fully there either.
Comment 3 Alok 2014-04-02 20:48:28 UTC 
This is tested on samsung galaxy tab3 and minix neo x7 mini device.
I have used various 1080p60 clips for this testing and all dropped frames big time.

gst_parse_launch("filesrc location=/storage/extSdCard/1_StarGaze10MbitHighCABAC1080p60.mp4 ! decodebin !queue ! eglglessink", &error);

//data->pipeline = gst_parse_launch("filesrc location=/storage/extSdCard/bbb_short_1080p.avi ! decodebin !queue ! eglglessink", &error);

Same is observed while playing RTSP 1080p60 stream.
Comment 4 Olivier Crête 2014-04-08 22:28:22 UTC 
Which Galaxy Tab 3? 7.0, 8.0 or 10.1 ? They use completely different SoCs. The Minix seems to be a Rockchip SoC.
Comment 5 Alok 2014-04-08 22:40:37 UTC 
Galaxy 8.0 device tab 3
Comment 6 Alok 2014-04-08 22:42:16 UTC 
yes minix neo X7 mini is Rockchip RK3188
Comment 7 Sebastian Dröge (slomo) 2014-10-08 07:36:48 UTC 
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.

*** This bug has been marked as a duplicate of bug 731204 ***