[Bug 732040] Caps intersection problems with meta:GstVideoOverlayComposition

[GStreamer (bugzilla.gnome.org)]

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

Sebastian Dröge (slomo) <slomo> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |NOTABUG

--- Comment #1 from Sebastian Dröge (slomo) <slomo at coaxion.net> 2014-06-22 16:33:20 UTC ---
Not a bug but intentional, and your workaround is exactly the solution :)
Relevant IRC log for the future:

<dj-death> it seems that elements can rely on 2 ways to get to know what
downstream can do for them
<dj-death> caps queries and allocation queries
<slomo> yes
<slomo> capsfeatures in the caps are requirements by downstream
<slomo> metas in the allocation query are things it supports but are not needed
<slomo> (so upstream can just ignore the stuff from the allocation query)
<dj-death> so textoverlay base it's caps responses on the downstream's caps
<dj-death> so if I don't put meta:GstVideoOverlayComposition in the video
sink's caps, textoverlay doesn't seem to know about downstream supporting that
<slomo> the problem is not textoverlay but upstream of textoverlay there
<dj-death> but if I do, then other plugins don't link anymore because caps
don't intersect anymore 
<slomo> because that upstream can only do the textuploadmeta if downstream can
do videooverlaycomposition
<slomo> well, it's the combination between upstream and textoverlay here
<dj-death> really?
<dj-death> because upstream (the video decoder) doesn't know about subtitles
<slomo> well, textoverlay can either render the subtitles on raw video. in that
case it does not care if downstream supports the videooverlay meta or not
<slomo> or it can create videooverlaymeta for anything else (GL textures,
EGLImages, vaapi surfaces, stuff)
<slomo> but then it requires downstream to actually be able to handle that
<-- aleb has quit (Remote host closed the connection)
<__tim> uhm
<__tim> what about case 3: downstream only supports raw video, but can blend
subtitles just fine?
<dj-death> yep, that's my understanding too
<__tim> that should be supported
<slomo> __tim: that's the first case, no?
<slomo> dj-death: so what you describe as workaround is actually the expected
solution :)
<dj-death> slomo: ahah no ;)
<slomo> dj-death: you can do (textuploadmeta, videooverlaymeta),
(textureuploadmeta), (sysmem)
<__tim> I understood the first case to be where textoverlay decides that it has
to do the overlaying/blending itself because downstream can't handle it
<dj-death> slomo: you have to consider the whole pipeline here, including the
decoder 
<slomo> dj-death: for simplicity, what's the decoder you care about here?
vaapidec?
<dj-death> slomo: yep
<dj-death> slomo: which queries downstream to figure out whether it can use
texture gl upload or not
* __tim is thinking of avdec_h264 ! textoverlay ! whateverblendsink btw
<slomo> dj-death: so the decoder sees that it can give downstream
textureuploadmeta if your videosink has videooverlaycomp in its caps
<slomo> dj-death: that's what the code in textoverlay is supposed to do
<dj-death> slomo: but, because textoverlay doesn't see the
meta:GstVideoOverlayComposition caps in the video sink's caps, it strips out
the texture gl upload caps from the sink's response
<slomo> dj-death: (and additionally the decoder sees that it can do sysmem and
whatever else)
<slomo> dj-death: yes, which is exactly what is expected there, no? your sink
can't do videooverlaycomposition, so textoverlay can't work with non-sysmem
<dj-death> slomo: no, my sink can do that
<slomo> __tim: that case is still supported as before
<slomo> dj-death: what's the caps in your sink now?
<slomo> put it into a pastebin :)
<__tim> ok
<slomo> __tim: the new code path only is for the non-sysmem cases
<slomo> dj-death: if your sink only has (textureuploadmeta), (sysmem) then
textoverlay will tell upstream only about sysmem
<slomo> dj-death: if your sink has (textuploadmeta, videooverlaymeta),
(textureuploadmeta), (sysmem) then textoverlay will tell upstream about these
three
<dj-death> dammit gst-inspect doesn't list my sink anymore
<slomo> dj-death: and if in the second case textoverlay only tells upstream
about sysmem, then you found a bug and we should look into that :)
<dj-death> slomo: ok so I can't just report (textuploadmeta, videooverlaymeta)
(sysmeme, videooverlaymeta)
<dj-death> slomo: I have to split cap features like this :
<slomo> yes you can't
<dj-death> alright :)
<dj-death> that's all good then
<slomo> each capsfeature is && combined, meaning that you need all of them at
once
<slomo> so in your case you need the 3 i mentioned above
<-- dantti has quit (Ping timeout: 255 seconds)
<slomo> for sysmem you don't specifically need videooverlaymeta... but you can
add it and it shouldn't hurt ;)
<dj-death> I actually have (textuploadmeta, videooverlaymeta),
(textureuploadmeta), (sysmem, videooverlaymeta), (sysmem) now
<slomo> and might make negotiation in even more complex situations work better
<slomo> sounds good
<dj-death> cool

-- 
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.