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 754040 - Investigate why caps negotiation is slower than in 1.4
Investigate why caps negotiation is slower than in 1.4
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other All
: Normal blocker
: 1.5.91
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2015-08-24 19:32 UTC by Thiago Sousa Santos
Modified: 2015-09-01 07:12 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Thiago Sousa Santos 2015-08-24 19:32:04 UTC
Doing some caps negotiation analysis comparing 1.4 with git master I found out that the time it takes on caps negotiation and prerolling is about the same. This came as a surprise as the accept-caps improvments should have brought this down.

Looking deeper it seems that taking a version before the accept-caps fixes the number and total time of caps queries were higher than 1.4 (quite a lot) and the accept-caps improvements merely brought those down to their 1.4 levels.

Filing this as a blocker to have this understood before 1.6 releases. Might just be that some bugs got fixed and more queries were needed to make things correct but better be safe than sorry here.
Comment 1 Thiago Sousa Santos 2015-08-24 23:50:06 UTC
Some times from a raspberry pi2 (average of 1000 runs of prerolling bbb - mp4+h264+aac):

queries: 338
total-caps-queries-time: 1001397839ns
preroll-time: 2163434599ns

queries: 391
total-caps-queries-time: 940275974ns
preroll-time: 2031405940ns

master without the accept-caps changes:
queries: 520
total-caps-queries-time: 2233977604ns
preroll-time: 3224977727ns

Will report for my laptop as soon as tests finish.
Comment 2 Thiago Sousa Santos 2015-08-25 12:04:54 UTC
For my laptop:
queries: 258
total-caps-queries-time: 104103881ns
preroll-time: 251615588ns

queries: 350
total-caps-queries-time: 120316397ns
preroll-time: 258229746ns

master without the accept-caps changes:
queries: 353
total-caps-queries-time: 199341504ns
preroll-time: 295635309ns
Comment 3 Sebastian Dröge (slomo) 2015-08-25 12:21:07 UTC
So it's specific to the RPi in some way. Are you using glimagesink on your laptop too? Are you using omxh264dec on the RPi, or also avdec_h264?
Comment 4 Thiago Sousa Santos 2015-08-25 12:58:44 UTC
For the RPi case:

* No OMX elements.

* One of the differences is that the RPi was using glimagesink for 1.4 and then the gl bin was added for 1.6, this adds a few more queries.

* The avdec elements seem to not proxy caps queries downstream. Going back to 1.4, videodecoder and audiodecoder had no caps query handling, falling back to pad's default. So more queries are happening in master as well.
Comment 5 Thiago Sousa Santos 2015-08-25 21:13:18 UTC
For the record, in number of queries
using xvimagesink: 239
using glimagesink: 342

glimagesink has 3 elements internally so every caps query that reaches it will add 3 queries. (as it is the last element, nearly every query of the video branch will reach it)

Additionally, every new element added to decodebin will have its output caps compared with it, so an accept-caps in the ghostpad of the bin does:

1) This is a proxy-pad, try an accept-caps downstream -> fails because caps is not compatible yet
2) Fallback to default implementation -> caps query and compare with the accept-caps -> fail

This adds another 3 or 4 caps queries at every attempt when usually with xvimagesink only 1 would be done.

I wonder if a proxy-pad should fallback to the default implementation at all in this case of accept-caps. What's the reason for that?
Comment 6 Thiago Sousa Santos 2015-08-25 21:22:48 UTC
(In reply to Thiago Sousa Santos from comment #5)
> For the record, in number of queries
> using xvimagesink: 239
> using glimagesink: 342
This is with git master.
Comment 7 Sebastian Dröge (slomo) 2015-08-26 09:14:51 UTC
The fallback to the default implementation seems useless indeed, yes
Comment 8 Sebastian Dröge (slomo) 2015-08-31 13:46:32 UTC
Anything left to be done here or is it all understood and considered ok now?
Comment 9 Thiago Sousa Santos 2015-09-01 00:38:46 UTC
I couldn't find anything that couldn't be justified as a bugfix or some new feature, so I guess it is alright.