GNOME Bugzilla – Bug 754040
Investigate why caps negotiation is slower than in 1.4
Last modified: 2015-09-01 07:12:56 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.
Some times from a raspberry pi2 (average of 1000 runs of prerolling bbb - mp4+h264+aac): master: queries: 338 total-caps-queries-time: 1001397839ns preroll-time: 2163434599ns 1.4: 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.
For my laptop: master: queries: 258 total-caps-queries-time: 104103881ns preroll-time: 251615588ns 1.4: 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
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?
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.
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?
(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.
The fallback to the default implementation seems useless indeed, yes
Anything left to be done here or is it all understood and considered ok now?
I couldn't find anything that couldn't be justified as a bugfix or some new feature, so I guess it is alright.