Re: [PATCH/RFC v1 0/7] Videobuf2 framework
Hello, On 2010-09-10 13:27, Mauro Carvalho Chehab wrote: 1) it lacks implementation of read() method. This means that vivi driver has a regression, as it currently supports it. Yes, read() is not yet implemented. I guess it is not a feature that would be deprecated, right? Yes, there are no plans to deprecate it. Also, some devices like cx88 and bttv allows receiving simultaneous streams, one via mmap, and another via read(). This is used by some applications to allow recording video via ffmpeg/mencoder using read(), while the main application is displaying video using mmap. Well, in my opinion such devices should provide two separate /dev/videoX nodes rather than hacking with mmap and read access types. Best regards -- Marek Szyprowski Samsung Poland RD Center -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v1 0/7] Videobuf2 framework
On Friday, September 10, 2010 09:38:44 Marek Szyprowski wrote: Hello, On 2010-09-10 13:27, Mauro Carvalho Chehab wrote: 1) it lacks implementation of read() method. This means that vivi driver has a regression, as it currently supports it. Yes, read() is not yet implemented. I guess it is not a feature that would be deprecated, right? Yes, there are no plans to deprecate it. Also, some devices like cx88 and bttv allows receiving simultaneous streams, one via mmap, and another via read(). This is used by some applications to allow recording video via ffmpeg/mencoder using read(), while the main application is displaying video using mmap. Well, in my opinion such devices should provide two separate /dev/videoX nodes rather than hacking with mmap and read access types. 1) It is in use so you can't just drop it. 2) The read() API is actually very useful for video devices that deal with compressed video streams. E.g. you can do things like 'cat /dev/video0 foo.mpg' It's been a long standing wish to convert the ivtv and cx18 drivers to videobuf, but it's always been too complex. With a new vb2 implementation it may become actually possible. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v1 0/7] Videobuf2 framework
On Fri, Sep 10, 2010 at 4:22 AM, Hans Verkuil hverk...@xs4all.nl wrote: It's been a long standing wish to convert the ivtv and cx18 drivers to videobuf, but it's always been too complex. With a new vb2 implementation it may become actually possible. FYI: KernelLabs has done a port of cx18 to videobuf. We just haven't submitted it upstream yet. I'm just mentioning this so nobody else feels the urge to take a crack at it. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v1 0/7] Videobuf2 framework
Em 10-09-2010 04:38, Marek Szyprowski escreveu: Hello, On 2010-09-10 13:27, Mauro Carvalho Chehab wrote: 1) it lacks implementation of read() method. This means that vivi driver has a regression, as it currently supports it. Yes, read() is not yet implemented. I guess it is not a feature that would be deprecated, right? Yes, there are no plans to deprecate it. Also, some devices like cx88 and bttv allows receiving simultaneous streams, one via mmap, and another via read(). This is used by some applications to allow recording video via ffmpeg/mencoder using read(), while the main application is displaying video using mmap. Well, in my opinion such devices should provide two separate /dev/videoX nodes rather than hacking with mmap and read access types. Why? V4L2 API allows to have multiple applications opening and streaming. There's nothing wrong with that, since it is a common practice in Unix to allow multiple opens for the same device. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v1 0/7] Videobuf2 framework
On Fri, 2010-09-10 at 10:22 +0200, Hans Verkuil wrote: On Friday, September 10, 2010 09:38:44 Marek Szyprowski wrote: Hello, On 2010-09-10 13:27, Mauro Carvalho Chehab wrote: 1) it lacks implementation of read() method. This means that vivi driver has a regression, as it currently supports it. Yes, read() is not yet implemented. I guess it is not a feature that would be deprecated, right? Yes, there are no plans to deprecate it. Also, some devices like cx88 and bttv allows receiving simultaneous streams, one via mmap, and another via read(). This is used by some applications to allow recording video via ffmpeg/mencoder using read(), while the main application is displaying video using mmap. Well, in my opinion such devices should provide two separate /dev/videoX nodes rather than hacking with mmap and read access types. 1) It is in use so you can't just drop it. 2) The read() API is actually very useful for video devices that deal with compressed video streams. E.g. you can do things like 'cat /dev/video0 foo.mpg' It's been a long standing wish to convert the ivtv and cx18 drivers to videobuf, but it's always been too complex. With a new vb2 implementation it may become actually possible. Steven has mmap() mostly done for the cx18 YUV stream: http://www.kernellabs.com/hg/~stoth/cx18-videobuf/ I provided him a slew of comments on the patchset, The comments were mostly just grunt work to move things around and clean it up than any major flaws. I only saw one problem that must be fixed before it is usable for the masses, IIRC. Maybe if there's a test case for trying out videobuf2, it's the cx18 driver where we want to use mmap() for YUV and read() for MPEG. Note Steven's changes allow one to tell the CX23418 to send YUV data in YUYV format vs. HM12. Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC v1 0/7] Videobuf2 framework
Hello, These patches add a new driver framework for Video for Linux 2 driver - Videobuf2. Videobuf2 is intended as a replacement for videobuf, the current driver framework, which will be referred to as videobuf1 for the remainder of this document. What is videobuf2? Videobuf2 is a Video for Linux 2 API-compatible driver framework for multimedia devices. It acts as an intermediate layer between userspace applications and device drivers. It also provides low-level, modular memory management functions for drivers. Videobuf2 eases driver development, reduces drivers' code size and aids in proper and consistent implementation of V4L2 API in drivers. Videobuf2 memory management backend is fully modular. This allows custom memory management routines for devices and platforms with non-standard memory management requirements to be plugged in, without changing the high-level buffer management functions and API. The framework provides: - implementations of streaming I/O V4L2 ioctls and file operations - high-level video buffer, video queue and state management functions - video buffer memory allocation and management Why a new framework? There have been many discussions in the V4L2 community about the feasibility of writing a new framework, as opposed to fixing the existing one. It has been agreed though that: - videobuf1 has major flaws and an attempt to fix it would end up in rewriting most of the code - many drivers depend on videobuf1 and since the changes would be major, an effort to adapt and test them all would not be realistically possible Due to the problems with videobuf most new drivers cannot use it. This leads to code replication and overcomplicated drivers. What is wrong with videobuf1? There are many problems with the current videobuf implementation. During a V4L2 mini-summit in Helsinki in June 2010, two presentations were delivered on this topic: - Laurent Pinchart videobuf - the good, the bad and the ugly http://linuxtv.org/downloads/presentations/summit_jun_2010/20100614-v4l2_summit-videobuf.pdf - Pawel Osciak Future of the videobuf framework http://linuxtv.org/downloads/presentations/summit_jun_2010/Videobuf_Helsinki_June2010.pdf These presentations highlighted many problems with videobuf. The most prominent include: - V4L2 API violations and wrong memory management design - it is impossible to pause streaming (buffers are freed on streamoff) - VIDIOC_REQBUFS(0) does not free memory - it is impossible to reallocate memory with VIDIOC_REQBUFS - video memory is allocated on mmap, qbuf or even on page fault, freed on unmap, streamoff or explicitly by drivers - per-buffer waitqueues - not extensible enough and thus not ready for new platforms and uses, especially considering embedded multimedia devices - very hard to add new memory handling routines and custom memory allocators - no or poor support for handling cache coherency, IOMMUs, - poor flexibility - only one do-it-all function for handling memory pinning, cache, sg-list creation, etc... - unused fields, code duplication, vague/inconsistent naming, obscure usage in some places... Many driver authors expressed their frustration with videobuf. Developers acknowledge its merits and would like to use it, but due mostly to its inflexible memory allocation schemes they are unable to do so. Main goals of the redesign - correct V4L2 API implementation, fixing videobuf1 problems and shortcomings - full separation between queue management and memory management - fully flexible, pluggable memory allocators and memory handling routines - more specialized driver callbacks, called at different points - support for new V4L2 API extensions, such as multi-planar video buffers Driver callbacks Driver callbacks have been redesigned for symmetry: - buf_init - called once, after memory is allocated or after a new USERPTR buffer is queued; can be used e.g. to pin pages, verify contiguity, set up IOMMU mappings, etc. - buf_prepare - called on each QBUF; can be used e.g. for cache sync, copying to bounce buffers, etc. - buf_finish - called on each DQBUF; can be used e.g. for cache sync, copying back from bounce buffers, etc. - buf_cleanup - called before freeing/releasing memory; can be used e.g. for unmapping memory, etc. The remaining driver callbacks have been slightly redesigned: - queue_negotiate - now incorporates multi-planar extensions; drivers return required number of buffers and planes per buffer - plane_setup - drivers return plane sizes Those two callbacks replace the old buf_setup. - buf_queue - basically stays the same Memory allocators and
Re: [PATCH/RFC v1 0/7] Videobuf2 framework
On 09/09/2010 06:19 PM, Pawel Osciak wrote: Hello, These patches add a new driver framework for Video for Linux 2 driver - Videobuf2. Sorry, I failed to mention that these patches depend on the multi-planar API extensions, but do not require multi-planar support in drivers and in vivi. Videobuf2 supports multi-planes, but can be used normally with current, single-planar API and drivers. Multi-planar API is available on this list and can also be pulled from here: The following changes since commit 67ac062a5138ed446a821051fddd798a01478f85: V4L/DVB: Fix regression for BeholdTV Columbus (2010-08-24 10:39:32 -0300) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-2.6-samsung v4l/multiplane-api Pawel Osciak (4): v4l: Add multi-planar API definitions to the V4L2 API v4l: Add multi-planar ioctl handling code v4l: Add compat functions for the multi-planar API v4l: fix copy sizes in compat32 for ext controls drivers/media/video/v4l2-compat-ioctl32.c | 229 +--- drivers/media/video/v4l2-ioctl.c | 420 ++--- include/linux/videodev2.h | 124 +- include/media/v4l2-ioctl.h| 16 ++ 4 files changed, 709 insertions(+), 80 deletions(-) -- Best regards, Pawel Osciak Linux Platform Group Samsung Poland RD Center -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v1 0/7] Videobuf2 framework
Hello Mauro, On 09/10/2010 02:53 AM, Mauro Carvalho Chehab wrote: Em 09-09-2010 06:19, Pawel Osciak escreveu: Hello, These patches add a new driver framework for Video for Linux 2 driver - Videobuf2. I didn't test the patches, but, from a source code review, they seem on a good shape. I did a few comments on some patches. There are a few missing features for them to be used with real drivers: Thank you for review. I will address your in-code comments in a bit, now for general comments. 1) it lacks implementation of read() method. This means that vivi driver has a regression, as it currently supports it. Yes, read() is not yet implemented. I guess it is not a feature that would be deprecated, right? There are some problems with read that are problematic: - not every device / memory type will be able to use it, as we need a way to allocate kernel memory for an operation and not every memory type may support it - there is no way to use it with multi-planar API, as it is not possible to read from multiple memory buffers (having multiple pointers) with read... But I guess it it could be added to work as before with single-planar buffers only, for compatibility. Also I am thinking about where read() should be implemented. It is something that will have to be emulated on top of normal streaming, as it is now done in videobuf1. So maybe a more generic read implementation would be a good idea? A separate layer that would be implementing read on top of streaming? It would not have to be limited to videobuf only then, drivers that support streaming but not using videobuf would be able to use it too. 2) it lacks OVERLAY mode. We can probably mark this feature as deprecated, avoiding the need of implementing it on videobuf2, but we need a patch for Documentation/feature-removal-schedule.txt, in order to allow the migration of the existing drivers like bttv and saa7134, where this feature is implemented, of course if people agree that this is the better way; If you think this feature can be deprecated, it might be a good idea. If not, I guess I will be able to take a stab at it when working with saa7134 and bttv, right? Should not require too much work to add. I just did not have a device to test it on, so I did not add it. It would be great if you could make the decision about what to do with this. I will try to follow your opinion and suggestions. 3) it lacks the implementation of videobuf-dvb; Yes... I have no experience with DVB, but I guess I can just get a DVB card and start hacking. Could you recommend a card? Technisat SkyStar 2? 4) it lacks an implementation for DMA S/G. Yes, I am planning to work on this next, I will be testing on saa7134 and maybe something else as well, probably a bttv. Please let me know if you have any suggestions or recommendations on which drivers I should be focusing. I am also hoping for Laurent's comments on this, since he was working on SG much more than I did. We need to address all the above issues, in order to use it, otherwise the migration of existing drivers would cause regressions, as features will be missing. Right, of course. Videobuf2 is a long time effort and I hope it will be evolving gradually. What I would like to assure you about is that I will not abandon it and will not limit myself to working only on embedded or Samsung device support. Videobuf2 is not only my in-Samsung project and I intend to be working on it outside my work responsibilities as well, supporting desktop and other platforms, as my time permits. I would like to address whatever you and others think is necessary and make videobuf2 useful for as many devices as possible. This is also why I am posting it earlier rather than later. I hope for people to point out features they would require and give their opinions early. I think that working together on this we will be able to gradually come up with a solution that would be useful and satisfying for most people. I would like to ask about your idea for the strategy of its development and inclusion. We will be posting a few drivers based on videobuf2 soon. Do you think it could be merged gradually, as features are added? It would be great if we could work on it and merge it gradually. Some people could already start using it in new drivers, others could start adding features to it, the API would be stabilizing and we would be having a solid base to work on. This is a long-term effort for many months or maybe years. It goes without saying that it will be harder to add everything in one go. Others might not be eager to adopt it if it is not an official effort either. And I cannot deny it, it would also make my job easier. As I said, I do not intend to leave it as it is now nor work on embedded support only. Also, we do not have to migrate all old drivers in one go, but that also goes without saying. As we discussed, videobuf1 will not go away anytime soon. I think we should consider
Re: [PATCH/RFC v1 0/7] Videobuf2 framework
Em 10-09-2010 00:20, Pawel Osciak escreveu: Hello Mauro, On 09/10/2010 02:53 AM, Mauro Carvalho Chehab wrote: Em 09-09-2010 06:19, Pawel Osciak escreveu: Hello, These patches add a new driver framework for Video for Linux 2 driver - Videobuf2. I didn't test the patches, but, from a source code review, they seem on a good shape. I did a few comments on some patches. There are a few missing features for them to be used with real drivers: Thank you for review. I will address your in-code comments in a bit, now for general comments. 1) it lacks implementation of read() method. This means that vivi driver has a regression, as it currently supports it. Yes, read() is not yet implemented. I guess it is not a feature that would be deprecated, right? Yes, there are no plans to deprecate it. Also, some devices like cx88 and bttv allows receiving simultaneous streams, one via mmap, and another via read(). This is used by some applications to allow recording video via ffmpeg/mencoder using read(), while the main application is displaying video using mmap. There are some problems with read that are problematic: - not every device / memory type will be able to use it, as we need a way to allocate kernel memory for an operation and not every memory type may support it - there is no way to use it with multi-planar API, as it is not possible to read from multiple memory buffers (having multiple pointers) with read... But I guess it it could be added to work as before with single-planar buffers only, for compatibility. Yeah, a multi-planar read() doesn't seem to make sense. Also I am thinking about where read() should be implemented. It is something that will have to be emulated on top of normal streaming, as it is now done in videobuf1. So maybe a more generic read implementation would be a good idea? A separate layer that would be implementing read on top of streaming? It would not have to be limited to videobuf only then, drivers that support streaming but not using videobuf would be able to use it too. I don't think we should try to cover drivers that don't use videobuf. 2) it lacks OVERLAY mode. We can probably mark this feature as deprecated, avoiding the need of implementing it on videobuf2, but we need a patch for Documentation/feature-removal-schedule.txt, in order to allow the migration of the existing drivers like bttv and saa7134, where this feature is implemented, of course if people agree that this is the better way; If you think this feature can be deprecated, it might be a good idea. If not, I guess I will be able to take a stab at it when working with saa7134 and bttv, right? Should not require too much work to add. I just did not have a device to test it on, so I did not add it. It would be great if you could make the decision about what to do with this. I will try to follow your opinion and suggestions. From Helsinki's comments, it seems that most people believe that we can deprecate it, as a feature similar to OVERLAY can be done by using USERPTR. Also, there's currently a problem with userspace applications and OVERLAY, and none is working to fix it. So, if nobody objects (and fixes the userspace applications), then I think that the better is to deprecate it. 3) it lacks the implementation of videobuf-dvb; Yes... I have no experience with DVB, but I guess I can just get a DVB card and start hacking. Could you recommend a card? Technisat SkyStar 2? You should get one that uses videobuf-dvb. I would seek for one using bttv, saa7134, cx88 or em28xx. It is hard to me to point you to an specific device, especially since I am at ISDB-T area. There are lots of supported devices, so the better is to just take a look at *-cards.c and seek for one DVB device that you could find near you. I'm sure you'll find lots of saa7134 cards and em28xx-based sticks with DVB support. 4) it lacks an implementation for DMA S/G. Yes, I am planning to work on this next, I will be testing on saa7134 and maybe something else as well, probably a bttv. Please let me know if you have any suggestions or recommendations on which drivers I should be focusing. I am also hoping for Laurent's comments on this, since he was working on SG much more than I did. bttv and saa7134 are the more complete/complex implementations. If you can make them work, porting videobuf2 to the other drivers will be trivial. We need to address all the above issues, in order to use it, otherwise the migration of existing drivers would cause regressions, as features will be missing. Right, of course. Videobuf2 is a long time effort and I hope it will be evolving gradually. What I would like to assure you about is that I will not abandon it and will not limit myself to working only on embedded or Samsung device support. Videobuf2 is not only my in-Samsung project and I intend to be working on it outside my work responsibilities as well, supporting
