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 732040 - Caps intersection problems with meta:GstVideoOverlayComposition
Caps intersection problems with meta:GstVideoOverlayComposition
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-06-22 14:01 UTC by Lionel Landwerlin
Modified: 2014-06-22 16:33 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Lionel Landwerlin 2014-06-22 14:01:16 UTC
Trying to get the Totem to work with video decode, I'm now looking at a scenario where I have a video with subtitles.
Here Totem is using the cluttergst video sink (master branch), which supports buffer with overlay composition meta informations as well as gl texture upload.

Problem 1:

Initially ClutterGstVideoSink wasn't advertising the meta:GstVideoOverlayComposition feature in its caps, even though through the allocation query it would respond that it supports overlay composition.

The result is that the textoverlay plugin would not see that capability from the video sink and therefore strips the meta:GstVideoGLTextureUploadMeta feature from the video sink's caps response (response then used by the decoder to determined whether gl textures can be sent through).

Problem 2:

After I added the meta:GstVideoOverlayComposition feature to the ClutterGstVideoSink caps, playbin was unable to link the ClutterGstVideoSink the videoconv/videoscale elements in the pipeline.

That is because there is not inclusive notion at the caps feature level, just equality. So buffers sent from the decoder with video/x-raw(meta:GstVideoGLTextureUploadMeta) caps and enriched with overlay composition meta information by textoverlay, would not be linked to the caps of video sink which is video/x-raw(meta:GstVideoGLTextureUploadMeta, meta:GstVideoOverlayComposition).



For now I solved these problems by adding caps with and without meta:GstVideoOverlayComposition feature to the ClutterGstVideoSink.
Comment 1 Sebastian Dröge (slomo) 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