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 743622 - ximagesink fails to allocate buffer size for greater than 4kx2k resolution
ximagesink fails to allocate buffer size for greater than 4kx2k resolution
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
1.x
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-01-28 05:57 UTC by swapnil
Modified: 2018-11-03 11:34 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description swapnil 2015-01-28 05:57:12 UTC
When tried to decode jpeg image with following pipeline,

gst-launch-1.0 filesrc location=<4kx2k jpeg file> ! jpegdec ! videoconvert ! ximagesink 
Below error was thrown.

ERROR: from element /GstPipeline:pipeline0/GstXImageSink:ximagesink0: Failed to create output image buffer of 4064x2704 pixels
Additional debug info:
ximagepool.c(401): ximage_memory_alloc (): /GstPipeline:pipeline0/GstXImageSink:ximagesink0:
could not get shared memory of 43956224 bytes
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...

Resolution of the image to be decoded was 4064x2704.
Comment 1 Vincent Penquerc'h 2015-01-29 11:01:14 UTC
It seems likely that you just have not enough shared memory:

cat /proc/sys/kernel/shmmax

I suppose xvimagesink could try to fallback to normal memory images in that case.
Comment 2 Tim-Philipp Müller 2015-01-29 11:12:36 UTC
I think there might be something else going on. When I tested that specific resolution I had problems, but other higher resolutions worked fine. shmmax is not the problem in my case at least.
Comment 3 Vincent Penquerc'h 2015-02-02 14:58:42 UTC
Fair enough. I just tried here, and it works for me after increasing shmmax, otherwise fails with the same error as above.

Looking at the code, it's a call to shmget with the actual number of bytes. I suppose it could have been that other processes were using shared memory, causing available shared memory to fluctuate (especually if close to the shmall, though mine seems to be set to my whole RAM).
Comment 4 GStreamer system administrator 2018-11-03 11:34:29 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/gst-plugins-base/issues/157.