<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/4.6.6"> </HEAD> <BODY TEXT="#000000" BGCOLOR="#ffffff"> Le jeudi 08 mai 2014 à 22:28 +0900, Makoto Harada a écrit : <BLOCKQUOTE TYPE=CITE> Hi Nicolas, Thank you so much for your reply. All of your comments are really helpful for me :-) <BLOCKQUOTE TYPE=CITE> 1. gst-launch-1.0 v4l2src io-mode=2 ! fakesink failed with following error message ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Failed to configure internal buffer pool. </BLOCKQUOTE> By using the code of following repositories, I confirmed that the basic pipeline described above is now working. </BLOCKQUOTE> Great. <BLOCKQUOTE TYPE=CITE> <A HREF="http://cgit.collabora.com/git/user/nicolas/gstreamer.git/log/?h=pool-nego-fix">http://cgit.collabora.com/git/user/nicolas/gstreamer.git/log/?h=pool-nego-fix</A> <A HREF="http://cgit.collabora.com/git/user/nicolas/gst-plugins-base.git/log/?h=pool-config-fix">http://cgit.collabora.com/git/user/nicolas/gst-plugins-base.git/log/?h=pool-config-fix</A> <A HREF="http://cgit.collabora.com/git/user/nicolas/gst-plugins-good.git/log/?h=v4l2-allocator">http://cgit.collabora.com/git/user/nicolas/gst-plugins-good.git/log/?h=v4l2-allocator</A> Then, we are thinking about the next step: applying your DMABUF work to our custom encoder plugin. When looking your code, it seems to me that your DMABUF related patches ( and GstV4l2BufferPool class) assumes that the target v4l2 plugins needs to be developped by using GstV4l2Object, which our custom encoder does not use. So, we are considering to re-write our plugin using GstV4l2Object. (Please correct me if I'm saying something wrong) </BLOCKQUOTE> This all depends. If it's a custom kernel API the GstV4l2Object won't be useful, it's it's v4l2, it's all much easier to add an encoder to the lot. Because of time, and because it would be on my free time, I didn't plan for having a generic encoder before 1.6. Some effort have been started by a student lately (Exynos 4, similar platform to the one are working on), <A HREF="https://bugzilla.gnome.org/show_bug.cgi?id=728438">https://bugzilla.gnome.org/show_bug.cgi?id=728438</A> . I haven't been very implicated as my focus is to get the decoder (and converter) ready for 1.4. About this, it's should happen today, and the branch nightmare will be past. I'm sure some help in making sure it's all stable in funky cases will be useful. Though, there is no requirement to use v4l2 gst framework in order to handle DMABUF. Typically, an encoder should be able to import dmabuf, hence you'll be able to detect if the memory in a buffer are dmabuf using <A HREF="gst-plugins-base-libs-dmabuf.html#gst-is-dmabuf-memory">gst_is_dmabuf_memory().</A> And then retreive the FD using gst_dmabuf_memory_get_fd() and import it. So far this allocator has only been used in "hardcoded" cases where only dmabuf is exchanged. So I suspect some more work needed, e.g. add allocation option and friends, in order to make proper decisions on time. <BLOCKQUOTE TYPE=CITE> And when looking your code more, we also noticed that there are gstv4l2videodec.[c|h], which would dramatically simply the implementation of each custom video decoder. Then, my question comes up. </BLOCKQUOTE> Note, this is a base class that is instantiable (no need to change add new code for each paltforms), and this is done per decoders already, as most platform have multiple decoders. <BLOCKQUOTE TYPE=CITE> Do you have any plan to develop gstv4l2videoenc.[c|h] in near future ? If yes, we would love to utilize it as the base class of our customer encoder. </BLOCKQUOTE> So the answer is yes, but more in mid/long term. Decoders are a bit more work, since they need to be split into categories (by encoded format), otherwise the element properties becomes a mess. Also, it's known that the V4L2 is not full features in term of codec configuration, hence vendors using it like freescale and samsung need to rely on custom properties (CID). This make it a little more work. <BLOCKQUOTE TYPE=CITE> Looking forward to hearing from you. (P.S I've inserted my comments below with [M.H] ) Kind Regards, Makoto Harada (2014年05月02日 02:09), Nicolas Dufresne wrote: </BLOCKQUOTE> <BLOCKQUOTE TYPE=CITE> <BLOCKQUOTE TYPE=CITE> <PRE> Le vendredi 02 mai 2014 à 00:42 +0900, Makoto Harada a écrit : </PRE> <BLOCKQUOTE TYPE=CITE> <PRE> Hello, I've tried the codes on your allocator branch [1]. Environment: - Linux version 3.2.0-4-686-pae (<A HREF="mailto:debian-kernel@lists.debian.org">debian-kernel@lists.debian.org</A>) </PRE> </BLOCKQUOTE> <PRE> That looks very old for doing DMABUF, or was it just for testing ? </PRE> </BLOCKQUOTE> [MH] Yes, it's just for testing. Our final goal is to run on kernel 3.4 which runs on ARM based application processor. </BLOCKQUOTE> Ok, for the reference the latest work I'm doing is on 3.8, though some patches has been sent upstream. Be ready from some kernel adaption, all this is really early work and has only been use for small use cases. <BLOCKQUOTE TYPE=CITE> <BLOCKQUOTE TYPE=CITE> <BLOCKQUOTE TYPE=CITE> <PRE> - gstreamer1.0, gst-plugins-base are fetched from master branch on official tree (as of 2014/4/30) - gst-plugins-good are fetched from [1] [1] <A HREF="http://cgit.collabora.com/git/user/nicolas/gst-plugins-good.git/log/?h=v4l2-allocator">http://cgit.collabora.com/git/user/nicolas/gst-plugins-good.git/log/?h=v4l2-allocator</A> I've tried the basic operation before trying DMABUF feature. However, unfortunately, it does run as expected. Symptom: 1. gst-launch-1.0 v4l2src io-mode=2 ! fakesink failed with following error message ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Failed to configure internal buffer pool. (log file with GST_DEBUG=6 is attached(tmp2.log). below is just the essense of the error message) v4l2 gstv4l2bufferpool.c:557:gst_v4l2_buffer_pool_set_config:<v4l2src0:pool:src> can't allocate, setting maximum to minimum bufferpool </PRE> </BLOCKQUOTE> <PRE> This just mean CREATE_BUFS is not supported, hence the min and max will be modified to the same. </PRE> <BLOCKQUOTE TYPE=CITE> <PRE> gstbufferpool.c:551:default_set_config:<v4l2src0:pool:src> config GstBufferPoolConfig, caps=(GstCaps)"NULL", size=(uint)0, min-buffers=(uint)2, max-buffers=(uint)2, allocator=(GstAllocator)"NULL", params=(GstAllocationParams)NULL; v4l2 gstv4l2object.c:3196:gst_v4l2_object_decide_allocation:<v4l2src0> error: Failed to configure internal buffer pool. </PRE> </BLOCKQUOTE> <PRE> That makes me realized I forgot to mention other changes are pending in other component. I had to fix the gst_buffer_pool_set_config () to implement what the doc says. Otherwise, buffer pools endup changing things and implementor of decide_allocate don't validate it. <A HREF="http://cgit.collabora.com/git/user/nicolas/gstreamer.git/log/?h=pool-nego-fix">http://cgit.collabora.com/git/user/nicolas/gstreamer.git/log/?h=pool-nego-fix</A> <A HREF="http://cgit.collabora.com/git/user/nicolas/gst-plugins-base.git/log/?h=pool-config-fix">http://cgit.collabora.com/git/user/nicolas/gst-plugins-base.git/log/?h=pool-config-fix</A> </PRE> </BLOCKQUOTE> [M.H] Thanks !! As I described, now this problem was solved by using the code on these repo. <BLOCKQUOTE TYPE=CITE> <BLOCKQUOTE TYPE=CITE> <PRE> My findings: 1. gst-plaugins-good from master branch on official tree worked as expected. 2. Error happens because can_allocate is 0 as shown below. gst_v4l2_buffer_pool_set_config (GstBufferPool * bpool, GstStructure * config) .... case GST_V4L2_IO_MMAP: can_allocate = GST_V4L2_ALLOCATOR_CAN_ALLOCATE (pool->vallocator, MMAP); According to the current code, it seems to me that kernel needs to support not only VIDIOC_REQBUFS but also VIDIOC_CREATE_BUFS ioctl, in order to use v4l2allocator. </PRE> </BLOCKQUOTE> <PRE> No, it detects if CREATE_BUFS is supported (normally it's not, there is like 2 drivers in the lot that supports that), and if not it ensure that configuration make it clear that it won't grow by setting max = min. When doing the allocation query/negotiation, one should re-read the modified configuration after set_config() failed, and check if the changes made by the pool are acceptable. If they are, it should simply call set_config() again. This will bring the pool to the state "configured" and set_active(TRUE) will now succeed. </PRE> <BLOCKQUOTE TYPE=CITE> <PRE> 3. Do we need to set "flags" to the allocator like below so that GST_V4L2_ALLOCATOR_CAN_ALLOCATE () macro can work as expected ? Please ignore if this is in your expectation. Maybe I'm misunderstanding something.... gst_v4l2_allocator_create_buf (GstV4l2Allocator * allocator) @@ -610,10 +648,20 @@ gst_v4l2_allocator_new (GstObject * parent, gint video_fd, allocator->type = format->type; allocator->format = *format; flags |= GST_V4L2_ALLOCATOR_PROBE (allocator, MMAP); flags |= GST_V4L2_ALLOCATOR_PROBE (allocator, USERPTR); flags |= GST_V4L2_ALLOCATOR_PROBE (allocator, DMABUF); + GST_OBJECT_FLAG_SET (allocator, flags); if (flags == 0) goto not_supported; </PRE> </BLOCKQUOTE> <PRE> Good catch, fixed uploaded to my branch. Again, I have no driver that I work with that actually support that :-S </PRE> </BLOCKQUOTE> [M.H] I'm happy to hear that. <BLOCKQUOTE TYPE=CITE> <BLOCKQUOTE TYPE=CITE> <PRE> Question: 1. Is there any special reason why VIDIOC_CREATE_BUFS ioctl is needed ? According to the following document, it seems to me that VIDIOC_CREATE_BUFS is not mandatory one. <A HREF="http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-create-bufs.html">http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-create-bufs.html</A> Our kernel currently does only support VIDIOC_REQBUS, and doe not support VIDIOC_CREATE_BUFS. I'm not so familiar with the multimedia portion, so please forgive me if I'm asking silly question. Any insight would be highly appreciated. Looking forward to hearing from you. </PRE> </BLOCKQUOTE> <PRE> Even worst, it's experimental. But as said, it's not needed. All you need is the fixes to properly configure pools. Note that these fixes are not yet right as they are not validating anything yet. </PRE> </BLOCKQUOTE> [M.H] OK. Understood. <BLOCKQUOTE TYPE=CITE> <PRE> thanks for looking into this, feedback is great, Nicolas </PRE> <PRE> _______________________________________________ gstreamer-devel mailing list <A HREF="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</A> <A HREF="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</A> </PRE> </BLOCKQUOTE> <PRE> _______________________________________________ gstreamer-devel mailing list <A HREF="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</A> <A HREF="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</A> </PRE> </BLOCKQUOTE> </BODY> </HTML>