Em Mon, 08 Jun 2015 16:42:48 +0200
Hans Verkuil <[email protected]> escreveu:
> On 06/08/2015 03:35 PM, Junghak Sung wrote:
> > Hello everybody,
> >
> > This patch series refactories exsiting Videobuf2, so that not only V4L2
> > but also other frameworks can use it to manage buffer and utilize
> > queue.
> >
> > I would separate existing Videobuf2-core framework into two parts - common
> > and v4l2-specific part. This work is as follows :
> >
> > 1. Separate existing vb2_buffer structure into common buffer and
> > v4l2-specific parts by removing v4l2-specific members and
> > embedding it into vb2_v4l2_buffer structure like this:
> >
> > struct vb2_v4l2_buffer {
> > struct vb2_buffer vb2;
> > struct v4l2_buffer v4l2_buf;
> > struct v4l2_plane v4l2_planes[VIDEO_MAX_PLANES];
> > };
> >
> > 2. Abstract the v4l2-specific elements, and specify them when the device
> > drives use them. For example, vb2_v4l2_buffer structure can be abstracted
> > by vb2_buffer structure, and device drivers can get framework-specific
> > object such as vb2_v4l2_buffer by using container_of().
> >
> > 3. Separate VB2-core framework into real VB2-core and v4l2-specific part.
> > This means that it moves V4L2-specific parts of VB2-core to v4l2-specific
> > part because current VB2-core framework has some codes dependent of V4L2.
> > As a result, we will have two VB2 files - videobuf2-core.c and
> > videobuf2-v4l2.c.
> >
> > Why do we try to make the VB2 framework to be common?
> >
> > As you may know, current DVB framework uses ringbuffer mechanism to demux
> > MPEG-2 TS data and pass it to userspace. However, this mechanism requires
> > extra memory copy because DVB framework provides only read() system call for
> > application - read() system call copies the kernel data to user-space
> > buffer.
> >
> > So if we can use VB2 framework which supports streaming I/O and buffer
> > sharing mechanism, then we could enhance existing DVB framework by removing
> > the extra memory copy - with VB2 framework, application can access the
> > kernel
> > data directly through mmap system call.
> >
> > This patch series is the first step for it.
> >
> > We have a plan for this work as follows:
> >
> > 1. Separate existing VB2 framework into three parts - VB2 common, VB2-v4l2,
> > and VB2-dvb. Of course, this change should not affect other v4l2-based
> > device drivers. This patch series includes some parts of this step.
> >
> > 2. Add new APIs for DVB streaming I/O. These APIs will be implemented
> > in VB2-dvb framework. So, we can remove unnecessary memory copy between
> > kernel-space and user-space by using these new APIs.
> > However, we leaves legacy interfaces as-is for backward compatibility.
> >
> > We are working on this project with Mauro and have a discussion with him
> > on IRC channel weekly. Nowaday, we are discussing more detailed DVB user
> > scenario for streaming I/O.
> >
> > The final goal of this project is to enhance current DVB framework.
> > The first mission is to achieve zero-copy functionality between kernel-space
> > and user-space with mmap system call. More missions are under consideration:
> > i.e., we could share the buffer not only between kernel-space and user-space
> > but also between devices - demux, hw video codec - by exporting a buffer
> > to dmabuf fd with VB2 framework.
> >
> > Any suggestions and comments are welcome.
> >
> > Best regards,
> > Junghak
> >
> > Junghak Sung (3):
> > modify the vb2_buffer structure for common video buffer and make
> > struct vb2_v4l2_buffer
> > move struct vb2_queue to common and apply the changes related with
> > that Signed-off-by: Junghak Sung <[email protected]>
> > make vb2-core part with not v4l2-specific elements
>
> Patch 2/3 didn't arrive at linux-media for some reason. Can you post it again?
Probably, the patch is too big. Vger doesn't accept patches bigger than
a few hundreds of KB. Not sure what's the current limit.
Junghak added the patches on his tree too:
http://git.linuxtv.org/cgit.cgi/jsung/dvb-vb2.git/log/?h=dvb-vb2
Junghak,
You may try to play with the git options that improve rename/copy files,
like:
--find-copies-harder
-M
-C
The last two options accepts a percentage parameter, like:
-C60 for detect changes that keep up to 60% of the original content.
and:
--diff-algorithm=minimal
--diff-algorithm=patience
Maybe with those options, the email produced by git format-patch will
be small enough to fit at the VGER mailing list limits.
If none of those work, please let us know.
Regards,
Mauro
> Thanks!
>
> Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
