Re: [V4L] vbi

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



Thanks for your comments.  VBI data is, for alot of people, a mundane
topic.  But, because it allows you to associate data with a video stream
on legacy analog video standards, and because of the emergence of
internet-enabled devices, there is huge potential for it.

> IMO VIDIOC_QUERYCAP is already overloaded with context dependant
> information we don't need here, it should focus on the kernel interface
> capabilities and not rough hardware hints. Other device types have
> VIDIOC_ENUM ioctls to enumerate formats, shouldn't we follow the major
> design principle? We could name the available formats, if only to tell
> there's a format the application fails to interpret because it's a
> custom format or has been defined at a later date. Also space for
> additional per format details we want to know, eg. hardware limitations.
> (I wonder why v4l2_format has a union and v4l2_fmtdesc hasn't?)

Yes, VIDIOC_ENUMSTD is probably a good way to go.  The driver
could return a string (e.g., "CC525" or "US Closed Caption") with
the number of bytes per read() (in this case, 2).  This way the standard
would not need to hard-code (pre-determine) the expected number of
bytes per sample by data type.  This would also reduce the bloat that
you also mentioned.

> A remarkable versatile device. Is bit/byte-endianess across devices an
> issue? Probably not. How about DMA, advantageous to store payload in
> adjacent locations? Difficulties because DMA writes additional
> information, padding necessary? How about output devices? The ones I'm
> familiar with are SAA 7111A and 7125 (output), they both only support
> CC525 polling via i2c.

We can either use this /dev/vbi as both VBI-in and VBI-out, or, use /dev/vbi
for VBI-in and /dev/vout for VBI-out.  The /dev/vout interface is odd, to
me,
because it appears to have been written around an MPEG encoder and
primarily used for DVD playback.  This is good, but the notion of /dev/vout
should include all video encoder applications.  Chrontel , Conexant
(formerly
Rockwell Semiconductor, formerly Brooktree, and soon to be an entirely
different company) and Geode each have encoders that can take your
VGA desktop and put it on a TV.  This is popular for computer games,
classroom instruction, set-top boxes, and other applications.

>From http://www.thedirks.org/v4l2/v4l2out.htm :

     "Video output devices can take digitized images from computer
     memory, such as those captured from a capture device, and
     convert them into a video signal. A video signal is a standard
     analog signal such as a PAL or NTSC signal, or a digital video
     signal such as an ITU-R601, or DV signal. A video output device
     can also output video to a graphics display frame buffer or overlay
     device."

For the driver that I am working on (Geode chipset), we will support
/dev/video, /dev/vbi, and /dev/vout.  The practical application for this
will be a 'set-top box'.  That is, the TV set will be for watching
television
and surfing the web.  Currently, we use /dev/vout for overlay (and alpha
blending).  I seems to me that since video overlay exists in video
controller memory that it should belong in /dev/video and not /dev/vout.
The notion of /dev/vout should be for what comes off of the composite
or S-video connector: analog video with embedded VBI data.

Anyway, we have this all in one driver which advertises itself as all
3 devices.

> It should be safe to assume all video data services are, and will be,
> line oriented and deliver in small units, or has anyone other news? How
> about DVB, is it something to consider or not? (Judging from the current
> pace, by the time v4l2 will make it into a stable kernel I have no hope
> any analogue device will still remain in use... :-)

The data services traditionally handled through the VBI of analog signals
will become special streams within the MPEG standard.  So, it would
be a completely different animal.  I don't think analog TV sets will go
away in my lifetime.  So, this API will be around.

Thoughts?

    -- Peter











[Index of Archives]     [Linux DVB]     [Video Disk Recorder]     [Asterisk]     [Photo]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Free Photo Albums]     [Fedora Users]     [Fedora Women]     [ALSA Users]     [ALSA Devel]     [Linux USB]

Powered by Linux