Q on DMABUF: how to get fd info from downstream plugin
Nicolas Dufresne
nicolas.dufresne at collabora.com
Thu May 8 07:56:43 PDT 2014
Le jeudi 08 mai 2014 à 22:28 +0900, Makoto Harada a écrit :
> 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.
Great.
> 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)
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), https://bugzilla.gnome.org/show_bug.cgi?id=728438 . 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 gst_is_dmabuf_memory(). 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.
>
> 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.
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.
>
> 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.
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.
>
> 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.
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.
> > > - 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
>
>
>
> _______________________________________________
> 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/cb658569/attachment-0001.html>
More information about the gstreamer-devel
mailing list