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 796680 - Supporting GLMemory in playbin
Supporting GLMemory in playbin
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
unspecified
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2018-06-26 13:39 UTC by Snir
Modified: 2018-11-03 12:46 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Snir 2018-06-26 13:39:18 UTC
Hi,

When the only available decoder for playbin is a decoder that uses GLMemory, playbin fails to build the pipeline if its sink does not support GlMemory (complains about missing components)

for example:

Assuming the only available h264\h265\vp8... decoder is nvdec (its src pad supports only GLMemory)

Trying:
"gst-launch-1.0 playbin uri=file:///path/to/h264/file video-sink=ximagesink"
will fail (although building it manually could work)

while trying:
"gst-launch-1.0 playbin uri=file:///path/to/h264/file (video-sink=glimagesink)"
will work.



I may be wrong with addressing this issue (opened it under gstreamer core) but seems to me its the lack of GLMemory support in playsink (cannot download/upload from gl input) is this a missing feature? bug? expected behavior?
Comment 1 Matthew Waters (ystreet00) 2018-06-27 10:55:11 UTC
I think this is mostly expected behaviour.

nvdec should ideally be combined with gldownload (either in a bin or downloading internally) to allow using video/x-raw for playbin and other use cases.
Comment 2 Snir 2018-06-27 12:55:31 UTC
Hi, thanks.

The this is I have an application that uses playbin to decode a general video stream (multiple types are plausible to be received) into an appsink(video/x-raw) element, than the frames are manipulated in memory.

So I'd expect playbin to be able to decode any stream if all necessary plugins for decoding it are available. Also if gl-supported-sink doesn't exist.

So, if playbin is indeed not expected to handle GLMem<->memory copies what would be the right & easy way to handle this issue?: 
1. To make the application support GLMemory (how to extract it from appsink and get the context?)
2. Make nvdec to support also non-GLMemory (but maybe there are more GL decoders)
3. Create an auto-gl-downloader\uploader plugin, (is there one alreay?)
4. Adding this feature to playbin\playsink(or decodebin maybe?)?
Comment 3 Matthew Waters (ystreet00) 2018-06-27 13:38:04 UTC
1. If the application explicitly wants GLMemory it has to know that already and would already have code to do that.
2. There are, they just also have a sysmem path to them as well which nvdec should also implement.
3. It's called gldownload/glupload.
4. Probably not going to happen.
Comment 4 GStreamer system administrator 2018-11-03 12:46:58 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/299.