Q on DMABUF: how to get fd info from downstream plugin

[Nicolas Dufresne]

Le vendredi 02 mai 2014 à 00:42 +0900, Makoto Harada a écrit :
> Hello, 
> 
> I've tried the codes on your allocator branch [1]. 
> 
> Environment:
>     - Linux version 3.2.0-4-686-pae (debian-kernel at lists.debian.org)
That looks very old for doing DMABUF, or was it just for testing ?

>     - 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]
> http://cgit.collabora.com/git/user/nicolas/gst-plugins-good.git/log/?h=v4l2-allocator 
> 
> 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

This just mean CREATE_BUFS is not supported, hence the min and max will
be modified to the same.

>  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.

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.

http://cgit.collabora.com/git/user/nicolas/gstreamer.git/log/?h=pool-nego-fix
http://cgit.collabora.com/git/user/nicolas/gst-plugins-base.git/log/?h=pool-config-fix

> 
> 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. 

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.

> 
>     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;

Good catch, fixed uploaded to my branch. Again, I have no driver that I
work with that actually support that :-S

> 
> 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. 
> 
> http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-create-bufs.html
>         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. 

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.

thanks for looking into this, feedback is great,
Nicolas

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140501/4c9a2c1e/attachment.sig>