[Bug 739332] Failing to connect vaapisink directly to decodebin

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=739332
  GStreamer | gst-plugins-base | git

--- Comment #9 from sreerenj <bsreerenj at gmail.com> 2014-11-18 11:06:06 UTC ---
As per the discussion in IRC(#gstreamer), the better solution to enable the
autoplugging of HW decoder in decodebin is increasing the HW decoder rank:
If no other objection, I will provide a patch for that.

This is the IRC log:

<sree_> slomo: actully vaapidecode can output video/x-raw(sysmem) ,,vaapidecode
! xvimagesink is a working scenario 
<slomo> sree_: why is vaapidecode not chosen then? does it have a lower rank
than e.g. avdec_h264?
<sree_> slomo: no, both have rank primary
<slomo> well, A comes before V :)
* twi_ has quit (Ping timeout: 250 seconds)
<sree_> slomo: aha :)
<sree_> slomo: but if upstream element query vaapisink, it will return
video/x-raw(VASurface) as first preference...so decdoebin should select a
decoder which is matching with that, right?
<slomo> there is no upstream yet
<slomo> decodebin does not have any srcpads at that time
* darkbasic has quit (Read error: Connection reset by peer)
* gandhi_m has quit (Read error: Connection reset by peer)
* darkbasic (~quassel at niko.linuxsystems.it) has joined #gstreamer
<slomo> without overriding the autoplug-* signals it has no way to select
elements other than their ranks and their caps
<sree_> okay, that I asked with out looking into the code !
* Tarnyko (~mbachmann at 46.18.96.46) has left #gstreamer
<sree_> may be to reorder elements with more number of capsfeatures in src_pad
as first in the list?
<slomo> this also means that in a standard decodebin scenario, vaapidecode only
knows that it can output video/x-raw(sysmem) without videometa btw
<slomo> no, i don't think there is a reason why more capsfeatures in general
should be better than less :)
<sree_> if ranks are the same, 
<sree_> the one with more capsfeatures supports more memory types,,
<sree_> so it is superior,,
<slomo> i don't think that's generally true
<sree_> we are using similar (bit different of course) logic in playbin...more
numb of common capsfeatreus between dec and sink... 
<slomo> yes, because there you can compare those capsfeatures with an actual
sink
<sree_> All HW decoders are supposed to support more memtypes than SW decoder
...so it is a clear superiority IMO
<sree_> we will get a benefit of hw decoding..is it a convincing explanation
for adding something like i proposed ? 
<sree_> may be i can create a new bug to track this?? WDT
<slomo> i don't think i agree with your assumptions
<sree_> so, you are concluding that there is no way to autoplug the HW decoder
in decodebin?
<sree_> hm,,there are multiple bugs waiting to get a fix for this
* lmr_ (~lmr at 179.110.43.152) has joined #gstreamer
<sree_> eg: #740110, #739031 
* Guest57714 is now known as prasu
<slomo> sree_: just give it a higher rank
<sree_> I hope giving a higher rank won't affect the use case of SW decoder
fallback if a particular codec profile is not supported by the HW decoder...
(It shouldn't , just making sure)
* desti_T2 (~desti at dslb-092-072-214-047.092.072.pools.vodafone-ip.de) has
joined #gstreamer
<slomo> sree_: no, that makes no difference assuming that vaapidecode properly
declares which profiles it supports on its sinkpad
<slomo> but that's an independent issue in any case, if it doesn't do ↑ it will
cause problems in any case
* gandhi_m (~gandhi_m at pd95bcf90.dip0.t-ipconnect.de) has joined #gstreamer
<sree_> slomo: k thanks

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.