V4L2 has a long history - the first gleam came into Bill Dirks's eye back around August of 1998. Development proceeded for years, and the V4L2 API was finally merged into the mainline in November, 2002, when 2.5.46 was released. To this day, however, quite a few Linux drivers do not support the newer API; the conversion process is an ongoing task. Meanwhile, the V4L2 API continues to evolve, with some major changes being made in 2.6.18. Applications which work with V4L2 remain relatively scarce.
V4L2 is designed to support a wide variety of devices, only some of which are truly "video" in nature:
- The video capture interface grabs video data from a tuner or camera device. For many, video capture will be the primary application for V4L2. Since your editor's experience is strongest in this area, this series will tend to emphasize the capture API, but there is more to V4L2 than that.
- The video output interface allows applications to drive peripherals which can provide video images - perhaps in the form of a television signal - outside of the computer.
- A variant of the capture interface can be found in the video overlay interface, whose job is to facilitate the direct display of video data from a capture device. Video data moves directly from the capture device to the display, without passing through the system's CPU.
- The VBI interfaces provide access to data transmitted during the video blanking interval. There are two of them, the "raw" and "sliced" interfaces, which differ in the amount of processing of the VBI data performed in hardware.
- The radio interface provides access to audio streams from AM and FM tuner devices.
Other types of devices are possible. The V4L2 API has some stubs for "codec" and "effect" devices, both of which perform transformations on video data streams. Those areas have not yet been completely specified, however, much less implemented. There are also the "teletext" and "radio data system" interfaces currently implemented in the older V4L1 API; those have not been moved to V4L2 and there do not appear to be any immediate plans to do so.
Video devices differ from many others in the vast number of ways in which they can be configured. As a result, much of a V4L2 driver implements code which enables applications to discover a given device's capabilities and to configure that device to operate in the desired manner. The V4L2 API defines several dozen callbacks for the configuration of parameters like tuner frequencies, windowing and cropping, frame rates, video compression, image parameters (brightness, contrast, ...), video standards, video formats, etc. Much of this series will be devoted to looking at how this configuration process happens.
Then, there is the small task of actually performing I/O at video rates in an efficient manner. The V4L2 API defines three different ways of moving video data between user space and the peripheral, some of which can be on the complex side. Separate articles will look at video I/O and the video-buf layer which has been provided to handle common tasks.
Subsequent articles will appear every few weeks, and will be added to the list below:
- Part 2: registration and open()
- Part 3: Basic ioctl() handling
- Part 4: Inputs and Outputs
- Part 5a: Colors and formats
- Part 5b: Format negotiation
- Part 6a: Basic frame I/O
- Part 6b: Streaming I/O
- Part 7: Controls
( Log in to post comments)
The Video4Linux2 API: an introduction
Posted Oct 12, 2006 2:15 UTC (Thu) by patrickbakker (guest, #25247) [Link]
I have read that the IVTV driver (for the Hauppage TV tuner cards amoung others) is moving away from its unique ioctls to more standard V4L2 ioctls. The primary agent of change is Hans Verkuil and I think he is working on fleshing out some of the V4L2 APIs to handle things like MPEG-II since the IVTV driver can capture video as a MPEG-II stream.
It may be useful to talk to Hans Verkuil for practical feedback on converting to V4L2 and for other portions of the V4L2 API like the MPEG-II stuff I already mentioned.
IVTV DriverThe Video4Linux2 API: an introduction
Posted Oct 12, 2006 11:25 UTC (Thu) by hverkuil (subscriber, #41056) [Link]
Some background info:As maintainer of ivtv I am working for over a year now to get it included
into the kernel. This turns out to be a huge job since in many ways this
driver is a first-of-its-kind driver.
Part of this effort is replacing ivtv-specific ioctls by a properly
designed V4L2 API: 2.6.14 added the sliced VBI API and 2.6.18 added the
API for encoding MPEG. The latter is not yet fully documented in the V4L2
spec (I'm working on that). Still to do is designing an MPEG decoding API
and (possibly, might remain ivtv-specific) an API for the On-Screen
Display. Designing such APIs is a time consuming process since MPEG
encoders/decoders are quite complicated.
I've no experience with converting V4L1 API to V4L2 API though since ivtv
always supported V4L2 AFAIK.
The VIVI driver; a great starting point for V4L2 driver writers
Posted Oct 12, 2006 4:18 UTC (Thu) by roskegg (subscriber, #105) [Link]
Video Technology Magazine ( http://www.videotechnology.com/) noticed the lack of good documentation for writing V4L2 drivers a year ago. Videotechnology Magazine staff John Sokol (Editor) and Ted Walther began coding the Virtual Video driver project. Part way through they handed the work over to Mauro Carvhalo Chehab for completion. It was finished just before Debconf6.The "vivi" driver which appeared in the 2.6.17 kernel is the outcome of that work. vivi is an abbreviation of "Virtual Video". The vivi driver creates a virtual video input device that produces real video.
The goal of the vivi project was to do a bare minimum "stub" V4L2 driver that would produce video output playable with xawtv. The project was an astounding success. vivi outputs a changing timestamp overlaid on some vertical color bars. vivi is simple. You can use it as a starting point for any video driver you wish to write.
The vivi code uses the most approved, idiomatic, current set of best practices for coding V4L2 drivers in the Linux kernel. If you use vivi as a starting point for your new V4L2 drivers, they will be less likely to break in the future than if you use any other driver as a starting point. You do not need to wonder if any of the code was written the way it was to work around some hardware specific bug. Being a virtual device, you know it wasn't.
Videotechnology Magazine sponsored a backport of vivi and the current V4L2 core to the 2.4 series of kernels. Whether you want a development or a tried and true kernel, you can benefit from vivi and the latest improvements in V4L2 because of this work.
The Video4Linux2 API: an introduction - complimentary information
Posted Oct 20, 2006 12:55 UTC (Fri) by mchehab (subscriber, #41156) [Link]
- > There are also the "teletext" and "radio data system" interfaces currently implemented in the older V4L1 API; those have not been moved to V4L2 and there do not appear to be any immediate plans to do so.
In fact, VBI interface handles both Closed Captions and Teletext. So, there's no need to have a separated teletext support.
At the raw VBI, the decoding proccess of Teletext is handled by userspace, while, with sliced VBI, this work is done by the hardware.
For Radio Data System, V4L2 uses a different approach, by using some special ioctls to haldle it, defined on include/media/rds.h.
The Video4Linux2 API: an introduction - complimentary information
Posted Jan 26, 2007 13:12 UTC (Fri) by mrechberger (guest, #42730) [Link]
what I noticed is that the userspace raw vbi decoder (libzvbi) is verypoor. Windows also uses raw vbi with USB devices and it works way more
accurate than in Linux with even 2x oversampling. If possible try to use
something else.
It was fun implementing support for raw vbi but as a fact there's almost
no practical use for it at the moment.
The Video4Linux2 API: an introduction
Posted Mar 15, 2007 16:12 UTC (Thu) by andre.goddard (guest, #38176) [Link]
Looking forward for the next installment.Thanks for the great article!
http://lwn.net/Articles/203924/
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
