GNOME Bugzilla – Bug 630442
xvimagesink, ximagesink: fallback to X*CreateImage() if X*ShmCreateImage() fails
Last modified: 2011-06-15 17:42:43 UTC
Created attachment 170940 [details] [review] patch ...
What problem is this trying to solve?
I´ll have the patch-writer expand on this one, but the problem (as I saw it) was that ximagesink on OSX was unable to do 720p. With this patch is works!
While X11 comes pre-installed on OS X 10.6, and was optional on previous versions, it's not the native windowing system (of course). Hence, it's not set up properly, including no configuration of X Shared Memory. Since the X11 installation used is X.org, it does have the X Shm Extension. And this will be picked up by the configuration script by default and X Shm will be turned on. It's only sys/ximage that uses X Shared Memory. Since X Shm isn't configured properly on OS X, the ximagesink will report that it's out of memory for any image larger than approximately 800x600. I haven't tested to find the exact limit. It can do 800x600, but not 1024x768 (and not 720p). By disabling X Shm, ximagesink does not have these memory problems and can easily do higher resolutions, including 720p. The patch preserves the ability to turn X Shm on for those that wants it. I.e. it will now default to not use X Shm on OS X, but it can still be explicitly requested with --enable-xshm.
Ok, that's approximately what I thought. This is the wrong way to fix it. The bug here is that x[v]imagesink doesn't fall back to normal X[v]Images if it fails to allocate one using X[v]ShmCreateImage(). This could happen anywhere, but is especially likely on OS/X since the default shmem limit is low. It seems reasonable to set xcontext->use_xshm to false once an allocation failure has happened, then it won't keep retrying. Bonus points for adding the size of the allocation that fails, in which case if any new allocation is smaller (because the window was resized) it will reattempt an XShm allocation. One detail -- if some images are allocated using XShm, the GstXvImageBuffer structure now needs a flag to indicate if the memory was allocated using XShm or not.
Indeed, this could happen anywhere and you're proposed solution would solve it for all relevant platforms. I can't commit to working on the proposed fix now though. I might have time to look into it at a later date. My use of ximagesink is puerly for testing purposes. As disabling X Shm solves that problem (meaning that in my case, it would always fall back to not use X Shm anyway), that's about as far as I can go with this right now.
*** Bug 630456 has been marked as a duplicate of this bug. ***
commit 7716358d045d90f43aecd7136a29c31f6ce75bdf Author: Sebastian Dröge <sebastian.droege@collabora.co.uk> Date: Thu May 26 12:33:08 2011 +0200 xvimagesink: Fallback to non-XShm mode if allocating the XShm image failed Fixes bug #630442. commit 34ae792075acece5b0adf7b7b8874a0255a2800d Author: Sebastian Dröge <sebastian.droege@collabora.co.uk> Date: Thu May 26 12:30:31 2011 +0200 ximagesink: Fallback to non-XShm mode if allocating the XShm image failed Fixes bug #630442.