GNOME Bugzilla – Bug 727236
ximagesrc fails to create an image after some time and recording stops
Last modified: 2015-04-03 10:26:59 UTC
This was first notice in Kazam Screencaster and now I was able to reproduce it with gst-launch-1.0 ximagesrc will die with 'error: could not create a 1920x1080 ximage' This happens somewhat at different times while recording. Sometimes 5-8 minutes into the recording and sometimes longer, 15-20. There is nothing out of the ordinary to notice on the system, RAM usage is ok and everything looks normal. Gst command line and pipeline that was used to gather the log data and to start recording: gst-launch-1.0 --gst-debug=ximagesrc:6 -e ximagesrc endx=1919 endy=1079 use-damage=false show-pointer=true ! queue ! videorate ! video/x-raw,framerate=24/1 ! videoconvert ! x264enc speed-preset=ultrafast pass=4 quantizer=15 threads=4 ! queue name=before_mux ! mux. pulsesrc device=alsa_output.pci-0000_00_1b.0.analog-stereo.monitor ! audio/x-raw ! audioconvert ! queue name=before_audio_conv ! audioconvert ! lamemp3enc ! queue ! mux. mp4mux name=mux faststart=1 streamable=1 faststart-file="/home/bigwhale/Videos/test.faststart.tmp" ! queue ! filesink location="/home/bigwhale/Videos/test.mp4" 2> gst-launch.log I've attached the the last second of log file.
Additional info: gst version is 1.2.3 running on Ubuntu 14.04. AMD Catalyst proprietary drivers are used. I was capturing while running Kerbal Space Program game.
I see no attachment ?
Created attachment 273176 [details] Log from gst-launch
After running gst-launch for several times, I accidentally overwrote the log file, so the above attachment is not the right one. I'll create another log.
Created attachment 273179 [details] Debug log with the error
Today I used gst-launch to capture with ximagesrc and encode to H264+FAA and muxed it to FLV. I used rtmpsink as a sink. Which was sending data to YouTube Live for an hour and a half. I was capturing 1920x1080 screen and it worked. YouTube complained about keyframes not being sent often enough. It appears that ximagesrc itself is able to run for a longer time, perhaps there is something wrong in the test pipeline I provided?
I've given a try to the script you propose for 15 minutes, and couldn't reproduce it, though it does not mean there is no problem. (note, I need to set remote=1, otherwise the images I get are miss-ordered, not sure if it's X/compositor bug or what). Then I've looked at the trace. The ximagesrc has a pool of image it picks from, and allocate more images when needed. In the trace we see that it regularly allocates images (though it's not the case here locally) and fail on one of these. I wonder if there is a leak, or if the buffers comes back invalid, get freed, and X could be freeing them asynchronously. Note that the ximagesink code has non-shm fallback, not sure if that would make a difference. I'm not sure what to do next, basically ximagesrc does not seem to do anything wrong. You could reduce the depth of the downstream pipeline, by using tune=zerolatency on x264enc, but is that a solution ?
I just captured and encoded with that pipeline for over an hour and had no problems. Then I ran Kazam and did the same, again with no problems. This is a very elusive thing. When I reported this bug, I was never able to capture for more than 20 minutes. I'd like to leave this open for now in case if it pops up for someone else.
It looks like you may be hitting shared memory limits. A single image at that size is 8 MB (assuming 32 bpp). This may be the same issue as https://bugzilla.gnome.org/show_bug.cgi?id=706066. It'd be interesting to know if, when it breaks, it's always after the same number of shm images created.
Created attachment 273583 [details] [review] avoid allocating unneeded alignment slack This does not fix the issue per se, but may ease shared memory pressure a bit. Since large shm allocations are typically page multiples, it may get you an extra image and move the issue further down the carpet (and maybe even down the hole under the carpet, if you get to the max concurrent image count, which may be due to downstream's max buffer lookahead).
Review of attachment 273583 [details] [review]: Looks like a really minor gain isn't it ?
Yes. Just a page, so usually 4 KB.
Just a page *if* the needed size was a multiple of the page size. Which it has a good chance of being. But this was free from my change for 706066 so why not :)
Comment on attachment 273583 [details] [review] avoid allocating unneeded alignment slack Let's commit this one, though for the bug itself, I think we should close it as invalid. I've also used ximagesink a lot latetely without this issue poping.
commit 3fd184da7811ba7073016316cfaa2d0a21d8c1c7 Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk> Date: Fri Apr 4 12:40:14 2014 +0100 ximage: do not allocate extra alignment slack for shared memory 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 is not needed. Since shared memory limits are low compared to RAM, we remove this waste. https://bugzilla.gnome.org/show_bug.cgi?id=727236