GNOME Bugzilla – Bug 706066
xvimagesink: Fails to allocate large xvimages but does not declare this limitation on the caps
Last modified: 2015-04-04 06:37:21 UTC
Created attachment 251731 [details] GST_DEBUG=xv*:6 Trying to decode PNG file with properties like Untitled.png: PNG image data, 4096 x 4096, 8-bit/color RGB, non-interlaced playbin seems to fails to show the image: [rygel] jens@laptop-jge: ~ $ gst-launch-1.0 playbin uri=file:///home/jens/Untitled.png Setting pipeline to PAUSED ... Pipeline is PREROLLING ... 0:00:00.734148306 12724 0x7f00dc003720 ERROR bufferpool gstbufferpool.c:491:gst_buffer_pool_set_active:<xvimagebufferpool1> start failed ERROR: from element /GstPlayBin:playbin0/GstPlaySink:playsink/GstBin:vbin/GstPlaySinkVideoConvert:vconv/GstVideoConvert:conv2: failed to activate bufferpool Additional debug info: gstbasetransform.c(1615): default_prepare_output_buffer (): /GstPlayBin:playbin0/GstPlaySink:playsink/GstBin:vbin/GstPlaySinkVideoConvert:vconv/GstVideoConvert:conv2: failed to activate bufferpool ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... Freeing pipeline ... xvinfo: [rygel] jens@laptop-jge: ~ $ xvinfo X-Video Extension version 2.2 screen #0 Adaptor #0: "Intel(R) Textured Video" number of ports: 16 port base: 91 operations supported: PutImage supported visuals: depth 24, visualID 0x20 number of attributes: 1 "XV_SYNC_TO_VBLANK" (range -1 to 1) client settable attribute client gettable attribute (current value is 1) maximum XvImage size: 8192 x 8192 Number of image formats: 5 id: 0x32595559 (YUY2) guid: 59555932-0000-0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed) id: 0x32315659 (YV12) guid: 59563132-0000-0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) id: 0x30323449 (I420) guid: 49343230-0000-0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) id: 0x59565955 (UYVY) guid: 55595659-0000-0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed) id: 0x434d5658 (XVMC) guid: 58564d43-0000-0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) Adaptor #1: "Intel(R) Video Sprite" number of ports: 1 port base: 107 operations supported: PutImage supported visuals: depth 24, visualID 0x20 number of attributes: 1 "XV_COLORKEY" (range 0 to 16777215) client settable attribute client gettable attribute (current value is 66046) maximum XvImage size: 2048 x 2048 Number of image formats: 2 id: 0x32595559 (YUY2) guid: 59555932-0000-0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed) id: 0x59565955 (UYVY) guid: 55595659-0000-0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed)
> maximum XvImage size: 2048 x 2048 This is a limitation of XV (through xvimagesink), though I feel that we could potentially have this handled in the caps negotiation, this way one could add a software scaler (videoscale) in there and get it to scaledown if needed. Meanwhile, you may want to try and work around with a pipeline like: gst-launch-1.0 playbin uri=file:///a.png video-sink="videoscale ! video/x-raw,with=[1,2048],height=[1,2048] ! xvimagesink" this will tell us if we are chasing the right issue. On my system the maximum size is much larger, 8192 x 8192, so this pipeline is not a solution for all systems.
That pipeline seems to be stuck in "Prerolling"
In theory xvimagesink should report this limitation on its sinkpad caps, and then videoscale would cause conversion. I'm sure that worked at some point
image is available at http://rygel-project.org/snapshot/testfiles/tmp/706066/sample.png and as audio file you can use any file, really. https://git.gnome.org/browse/gupnp-dlna-media/tree/strict/audio/NiN_Ghosts_IV_34.mp3 seems to "work" here, if you need a definite file.
Crap, wrong bug ;) sorry. Works fine with 0.10 1.0.x doesn't error out but also doesn't show the image.
I just ran some tests. Xvimagesink reports the limitations correctly on its caps and it seems to work here with latest git master. Did you try that? Can you get a lot that includes GST_DEBUG=*xv*:9,xcontext:9,*basetransform*:9 or a full GST_DEBUG=9 log? Maybe it will show us better what exactly is happening.
Created attachment 256021 [details] GST_DEBUG=9 log Did not work for me with git master...
From the logs, caps negotiation is working correctly. The issue is when calling some shared memory handling functions. From xvimageallocator.c:455, one of those is failing for you: /* get shared memory */ mem->SHMInfo.shmid = shmget (IPC_PRIVATE, mem->xvimage->data_size + align, IPC_CREAT | 0777); if (mem->SHMInfo.shmid == -1) goto shmget_failed; /* attach */ mem->SHMInfo.shmaddr = shmat (mem->SHMInfo.shmid, NULL, 0); if (mem->SHMInfo.shmaddr == ((void *) -1)) goto shmat_failed; /* now we can set up the image data */ mem->xvimage->data = mem->SHMInfo.shmaddr; mem->SHMInfo.readOnly = FALSE; if (XShmAttach (context->disp, &mem->SHMInfo) == 0) goto xattach_failed; Unfortunately the log doesn't tell which one. Could you debug and report where does it fail? It works here, could be something specific to your system.
This would mean that it can handle those dimensions in theory but just allocation fails... or maybe just a broken XV driver
breaking into that function, it looks like the shmget call is failing
Well, I'd say it's a bug in your XV driver. It claims to support up to "maximum XvImage size: 8192 x 8192" but then fails to allocate memory for that. There's not much we can do about that because at that point xvimagesink is already chosen and everything negotiated.
well, what's the difference with 0.10 then where it works.
Do you have a debug log for 0.10?
Also, I wonder if this can't be checked in the accept caps query already somehow? (Note: didn't check the code)
Created attachment 256407 [details] GST_DEBUG=9 log for GStreamer 0.10
So that apparently succeeds to allocate XVImages for the same configuration... must be a difference in the details of the XVImage, or some other change. Interesting :) Could you check via gdb what happens different between 0.10 and 1.x in the relevant code that allocates the XVImage and calls shmGet and all that?
stepping through the code, the difference is in the shmget call: 0.10 (xvimagesink.c:645) shmget (IPC_PRIVATE, xvimage->size, IPC_CREAT | 0777) 1.0 (xvimageallocator.c:457) shmget (IPC_PRIVATE, mem->xvimage->data_size + align, IPC_CREAT | 0777) where align is hardcoded to 15 on the beginning of the function. If I remove the "+ align" in that call, it works as expected.
An 8 bit 4096x4096 image would be... 16 MB. Would your shm size max out at 16 MB ? sysctl -a | grep shm You can also log data_size, in case the 8 bits get unpalettized to 16 or 32 bits (32 MB ot 64 MB (phew, lots)).
(I mean, adding 15 to exactly 16 MB seems like this might trip such a plausible limit, if there is one; my limit here is 32 MB).
kernel.shm_next_id = -1 kernel.shm_rmid_forced = 0 kernel.shmall = 2097152 kernel.shmmax = 33554432 kernel.shmmni = 4096 vm.hugetlb_shm_group = 0
That's I guess 32MB (shmmax = 33554432).
Created attachment 273582 [details] [review] do not add alignment slack for shm This should fix your issue, while preserving the original fix, which was only needed for normal RAM. Can you please double check ?
*** Bug 731125 has been marked as a duplicate of this bug. ***
commit 964ea678dafcf4c2ad022e4c6f9948e3cec902fa Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk> Date: Fri Apr 4 12:32:14 2014 +0100 xvimagsink: fix failure to allocate large shared memory blocks A previous patch increased allocations by 15 bytes in order to ensure 16 byte alignment for g_malloc blocks. However, shared memory is already block aligned, and this extra 15 bytes caused allocation to fail when we were already allocating to the shared memory limit, which is a lot smaller than typical available RAM. Fix this by removing the alignment slack when allocating shared memory. https://bugzilla.gnome.org/show_bug.cgi?id=706066 No comment on whether the patch fixed it, but it seems certain, so deemed fixed.
Ah, sorry. Yes, the patch fixed it