Q on DMABUF: how to get fd info from downstream plugin
Makoto Harada
makotouu at gmail.com
Thu May 8 06:28:56 PDT 2014
Hi Nicolas,
Thank you so much for your reply.
All of your comments are really helpful for me :-)
> 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.
By using the code of following repositories, I confirmed that the basic pipeline
described above is now working.
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
http://cgit.collabora.com/git/user/nicolas/gst-plugins-good.git/log/?h=v4l2-allocator
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)
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.
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.
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:
> 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 ?
[MH] Yes, it's just for testing. Our final goal is to run on kernel 3.4 which
runs on ARM based application processor.
>> - 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
>
[M.H] Thanks !! As I described, now this problem was solved by using the code on
these repo.
>> 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
[M.H] I'm happy to hear that.
>> 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.
[M.H] OK. Understood.
> thanks for looking into this, feedback is great,
> Nicolas
>
>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140508/b3879381/attachment.html>
More information about the gstreamer-devel
mailing list