GNOME Bugzilla – Bug 732288
x264enc: Does not request enough buffers in allocation query
Last modified: 2014-07-25 18:41:19 UTC
Created attachment 279330 [details] stdout and stderr output I have successfully compiled gstreamer1.0 from git source june 23,2014 (gstreamer, base, good, bad, ugly, libav) in Ubuntu 12.. However, gst-launch-1.0 fails with v4l2src saying failed to allocate buffer. On the other hand, gst-launc-0.1 (came with Ubuntu release) runs fine and does not fail with such error. I found the same issue with 1.3 source tree. ------------------log----------------- #gst-launch-1.0 v4l2src device=/dev/video0 ! 'video/x-raw, width=640, height=480, framerate=15/1' ! queue ! videoconvert ! x264enc ! rtph264pay pt=96 ! udpsink host=127.0.0.1 port=5000 Setting pipeline to PAUSED ... Pipeline is live and does not need PREROLL ... Setting pipeline to PLAYING ... New clock: GstSystemClock Redistribute latency... 0:00:04.152979362 30179 0x8a5770 ERROR v4l2allocator gstv4l2allocator.c:1326:gst_v4l2_allocator_dqbuf:<v4l2src0:pool:src:allocator> failed dequeuing a mmap buffer: Invalid argument 0:00:04.153024426 30179 0x8a5770 ERROR v4l2allocator gstv4l2allocator.c:1338:gst_v4l2_allocator_dqbuf:<v4l2src0:pool:src:allocator> The buffer type is not supported, or the index is out of bounds, or no buffers have been allocated yet, or the userptr or length are invalid. ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Failed to allocate a buffer Additional debug info: gstv4l2src.c(736): gst_v4l2src_create (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0 Execution ended after 0:00:04.073653279 Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... ----------------------------- /dev/video0 is a USB webcam, vlc can open it either with v4l2. Attached file contains the stdout and stderr output with GST_DEBUG=v4l*:6
0:00:04.120210834 [333m 458[00m 0x1471f70 [31;01mERROR [00m [00m v4l2allocator gstv4l2allocator.c:1326:gst_v4l2_allocator_dqbuf:<v4l2src0:pool:src:allocator>[00m failed dequeuing a mmap buffer: Invalid argument 0:00:04.120215825 [333m 458[00m 0x1471f70 [31;01mERROR [00m [00m v4l2allocator gstv4l2allocator.c:1338:gst_v4l2_allocator_dqbuf:<v4l2src0:pool:src:allocator>[00m The buffer type is not supported, or the index is out of bounds, or no buffers have been allocated yet, or the userptr or length are invalid. 0:00:04.120220062 [333m 458[00m 0x1471f70 [33;01mWARN [00m [00m v4l2src gstv4l2src.c:736:gst_v4l2src_create:<v4l2src0>[00m error: Failed to allocate a buffer ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Failed to allocate a buffer PS: if you want to dump logs to a file, please use GST_DEBUG_NO_COLOR=1 :)
It seems to run for a while, and then suddenly fail. It most likely fail in the driver. Also, a driver bugs is exposed, as it does not update flags correctly. To go forward, and find a solution, we would need to get some kernel traces, as "invalid argument" is used nearly everywhere in the kernel. Also, providing kernel version and which drivers (most of the time it's UVC for USB webcams, but there is couple non-UVC drivers too). Also, please compare results with and without libv4l2, and specify version of libv4l2 being used, as the rework of v4l2 framework have rendered visible few bugs in that library.
With version 1.3.3 ,My x264enc works fine, but x265enc have the same problem. When this happened , the x265 encoder would have many frames to input without encoded result to output. So this error may be caused by v4l2src buffer occupied by x265encoder. I found that only 2 buffers allocated by default in v4l2src , if the encoder don't release the buffer , the v4l2src will has no buffer to capture picture, the line in /gst-plugins-good-1.3.3/sys/v4l2/gstv4l2allocator.c if (v4l2_ioctl (allocator->video_fd, VIDIOC_DQBUF, &buffer) < 0) goto error; will report this error. In gst-plugins-good-1.3.3/sys/v4l2/gstv4l2object.h, I change GST_V4L2_MIN_BUFFERS from 2 to 32，my x265enc works fine with out that error, but this change sounds so ugly . How to change the buffer numbers of the v4l2src plug-in?
It should have stalled rather then failed, but this is another issue. The problem here is that you need to expose how many buffers you'll need in the allocation query (see propose_allocation() virtual method of the encoder base class). This will let v4l2 know how many buffers to allocate.
As the other bug is fixed now, it properly stalls. Not we need to fix x264enc to request enough buffers.
Created attachment 280186 [details] [review] [PATCH] videoencoder: Don't delay set_format This prevent implementing allocation query, as the format need to be known in order to determin the size and number of buffers needed. https://bugzilla.gnome.org/show_bug.cgi?id=73228 --- gst-libs/gst/video/gstvideoencoder.c | 17 ++--------------- 1 file changed, 2 insertions(+), 15 deletions(-)
Created attachment 280187 [details] [review] [PATCH] x264enc: Request buffers in allocation query https://bugzilla.gnome.org/show_bug.cgi?id=73228 --- ext/x264/gstx264enc.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)
Created attachment 280188 [details] [review] [PATCH] v4l2object: Don't skip configuration if active Bug 728268 has been fix. If the configuration is different, pool will now try to deactivate the pool in order to update the config --- sys/v4l2/gstv4l2object.c | 9 --------- 1 file changed, 9 deletions(-)
Created attachment 280189 [details] [review] [PATCH] v4l2object: Don't share own pool if min exceed V4L2 capacity If the minimum required buffer exceed V4L2 capacity, don't share down pool. This allow support very high latency, like with x264enc default encoding settings. https://bugzilla.gnome.org/show_bug.cgi?id=73228 --- sys/v4l2/gstv4l2object.c | 24 ++++++++++++++---------- 1 file changed, 14 insertions(+), 10 deletions(-)
So these are for after the freeze. As some more decoder will need to be revisited, I'll try to come up with a workaround (similar to what happened in 1.2 for the upcoming 1.4 release.
Created attachment 280193 [details] [review] [PATCH] v4l2bufferpool: Workaround elements not requesting any buffers This is a workaround for element that don't request buffers when they should. https://bugzilla.gnome.org/show_bug.cgi?id=73228 --- sys/v4l2/gstv4l2bufferpool.c | 6 ++++++ 1 file changed, 6 insertions(+)
This last one is a workaround, which would be similar to what 1.2 was doing.
Comment on attachment 280187 [details] [review] [PATCH] x264enc: Request buffers in allocation query That seems safe for 1.4 too
Comment on attachment 280186 [details] [review] [PATCH] videoencoder: Don't delay set_format Seems fine to me for 1.6... but why did we do this complicated delaying at all? Can you investigate? Maybe there was a reason we need to consider :) Also you probably want to get rid of the do_caps boolean now
(In reply to comment #14) > (From update of attachment 280186 [details] [review]) > Seems fine to me for 1.6... but why did we do this complicated delaying at all? > Can you investigate? Maybe there was a reason we need to consider :) > Should have added the reference in the commit log I guess, see: https://bugzilla.gnome.org/show_bug.cgi?id=680614 > Also you probably want to get rid of the do_caps boolean now Ok, I thought it was removed, will fix.
(In reply to comment #13) > (From update of attachment 280187 [details] [review]) > That seems safe for 1.4 too This patch has no effect without the base class fix, input_state is always NULL right now, hence the allocation query will always fail. I would try and make sure if input_state is missing that we endup doing that same as before. At least, we would ensure the a pool is provided, and that no copy due to stride is done ?
Ready for 1.4. commit d03bcba3db15d06dbdea6b776a6f28ed2f03272a Author: Nicolas Dufresne <nicolas.dufresne@collabora.com> Date: Tue Jul 8 17:50:47 2014 -0400 v4l2bufferpool: Workaround elements not requesting any buffers This is a workaround for element that don't request buffers when they should. https://bugzilla.gnome.org/show_bug.cgi?id=732288
Comment on attachment 280186 [details] [review] [PATCH] videoencoder: Don't delay set_format commit ce50fc221e8a795d7cfedf471d239d4a9d3bf824 Author: Nicolas Dufresne <nicolas.dufresne@collabora.com> Date: Tue Jul 8 16:59:37 2014 -0400 videoencoder: Don't delay set_format This prevent implementing allocation query, as the format need to be known in order to determin the size and number of buffers needed. Note: This may lead to few regressions that will need fixing https://bugzilla.gnome.org/show_bug.cgi?id=732288
Comment on attachment 280188 [details] [review] [PATCH] v4l2object: Don't skip configuration if active commit e196906b993285f3405690f6240f5dcd491ae9ea Author: Nicolas Dufresne <nicolas.dufresne@collabora.co.uk> Date: Sat May 24 19:02:59 2014 -0400 v4l2object: Remove is_active checks These checks are no longer required with recent change to the bufferpool. This should allow changing the configuartion, hence the way forward renegotiation support. https://bugzilla.gnome.org/show_bug.cgi?id=728268
(In reply to comment #19) > (From update of attachment 280188 [details] [review]) > commit e196906b993285f3405690f6240f5dcd491ae9ea > Author: Nicolas Dufresne <nicolas.dufresne@collabora.co.uk> > Date: Sat May 24 19:02:59 2014 -0400 > > v4l2object: Remove is_active checks > > These checks are no longer required with recent change to the bufferpool. > This > should allow changing the configuartion, hence the way forward > renegotiation > support. > > https://bugzilla.gnome.org/show_bug.cgi?id=728268 Sorry, wrong one.
Comment on attachment 280188 [details] [review] [PATCH] v4l2object: Don't skip configuration if active was don differently elswhere, so just marking obsolte.
Comment on attachment 280189 [details] [review] [PATCH] v4l2object: Don't share own pool if min exceed V4L2 capacity commit 3df949c7454b39d0394c4d9c6583393972edeff0 Author: Nicolas Dufresne <nicolas.dufresne@collabora.com> Date: Tue Jul 8 14:31:59 2014 -0400 v4l2object: Don't share own pool if min exceed V4L2 capacity If the minimum required buffer exceed V4L2 capacity, don't share down pool. This allow support very high latency, like with x264enc default encoding settings. https://bugzilla.gnome.org/show_bug.cgi?id=732288
Comment on attachment 280187 [details] [review] [PATCH] x264enc: Request buffers in allocation query commit 8aea88d2616c3be8dd30a883534031d832872c9c Author: Nicolas Dufresne <nicolas.dufresne@collabora.com> Date: Tue Jul 8 16:45:45 2014 -0400 x264enc: Request buffers in allocation query https://bugzilla.gnome.org/show_bug.cgi?id=73228
commit 287517d6a9803445b0e9afcfc144afa713b7b1b0 Author: Nicolas Dufresne <nicolas.dufresne@collabora.co.uk> Date: Fri Jul 25 14:30:33 2014 -0400 Revert "v4l2bufferpool: Workaround elements not requesting any buffers" This was a tempory workaround, we should fix the encoders that do not negotatiate the amount of buffers they need. This reverts commit d03bcba3db15d06dbdea6b776a6f28ed2f03272a. That's it, time to fix decoders if you see one being broken.