Re: [V4L] vbi

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



Peter Lohmann wrote:
> 
> Ideally, the specification of the expected data format would not depend on
> the size of the buffer provided. Also, since different parts of the world
> use the VBI region for different things, no assumption should be made as to the
> data format or which line the data would be on.

> Maybe we could specify flags for these so that the user program and driver
> can communicate the formats capable of slicing via the VIDIOC_QUERYCAP and
> the format desired or currently selected via the VIDIOC_G_FMT and
> VIDIOC_S_FMT IOCTLs.

Let's start with VIDIOC_QUERYCAP. Presumed we won't add a new device
type v4l2_cap has to diversify into raw vbi, sliced data or flag both
capabilities. If, however, the sliced api works for other (radio...)
services as well one should keep the raw vbi api strictly video and
create another general purpose sliced data api.

Sliced formats known by the hardware must be enumerated, when I think
about it v4l2_cap is probably the wrong place.

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?)

Adding BUF_TYPE_SLICED and a v4l2_sliced_format looks fine to me, I
don't feel comfortable re-using v4l2_vbi_format for a completely
different job, always assumed we will in fact end up with a mostly
incompatible api. The disadvantage is more bloat compared to a bitmask
in v4l2_cap and extended semantics for v4l2_vbi_format.sample_format et
al.

Can we agree a serial stream of payload is out of question because it's
vital to associate bytes with field and line numbers? That seems to
leave two options, a stream of variable sized units of header + payload,
or data stored in a 2d array.

Suppose raw vbi like direct mapping of scan lines to array lines. It
can be a quite large (or split) array when you truly don't care about
the source line, or services are encoded way apart, but let's assume we
get away with a number of canonical VBI lines, say 25 per field. Empty
lines (not carrying any information) must be unambiguously marked and
also typed if we allow format multiplexing, so a header seems
unavoidable, or be that flags. The array width can be determined
implicitly by the requested format, to reverse your idea, eg. CC 2
bytes, System B Teletext 42 bytes, VPS 13 bytes. Or determined by the
widest format requested, or some arbitrary constant eg. 64 bytes. I'm
only concerned we regret the latter when new, larger formats appear.

Suppose we make the buffer variable in height by adding field and line
numbers to each array line, no more gaps and the app has to parse a
stream as described above, line by line. Fine for read() and write(),
but how would it work with streaming i/o where the buffer size is
predetermined at mmap()ing time and one timestamp associated with all
the buffer contents?

Possibilities I see include: a) Each buffer holds only one line of
sliced data, prohibitively expensive. b) We concatenate buffers, eg.
stamp #1, first ten lines; stamp #1, next ten lines; stamp #1, remaining
five lines, rest unused; stamp #2, next frame... a packetized elementary
stream.:-) c) Buffers must provide enough room for one field or frame,
eg. 25 or even 625 lines. d) Each line gets its own timestamp. e) No
streaming i/o, no kernel timestamping allowed. :-( One shouldn't forget
about future kiobufs, but it doesn't seem to make a big difference.

> The Philips SAA7114 can be programmed to expect the following data
> formats:
> 
> WST625 Teletext EuroWST, CCST
> CC625 European Closed Caption
> VPS VPS (video programming service)
> WSS Wide Screen Signalling
> WST525 US teletext (WST)
> CC525 US closed Caption (line 21)
> Intercast Raw
> Gen. Text Teletext programmable
> VITC625 VITC/EBU Timecodes (Europe) programmable
> VITC625 VITC/SMPTE Timecodes (USA) programmable
> NABTS US NABTS
> Japtext Moji (Japanese)
> JFS Japanese format switch (L20/22)

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.

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... :-)

Michael





[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