> You're right sliced data services aren't in scope of the v4l2 vbi spec.
> It was planned but didn't get in due to lack of expertise (amongst RDS
> and who knows what else). The idea was to pass sliced data as small
> packets including the data type, field number, line number and payload.
> Data type is a bit mask, you could request more than one type and mix
> the packets (of constant length?), eg. Teletext plus VPS for country and
> network identification. Field and line number tell where the bit slicer
> found the data, a crop window makes less sense here. I don't really have
> a brilliant idea how this could fit nicely with streaming i/o.
>
> On a historical note, I didn't expect many apps to open the raw vbi
> interface directly except for special purposes. The late libv4l2 would
> provide a module opening raw or sliced devices, transcoding (or not) the
> raw vbi data, and broadcasting (the same) data packets to any number of
> listeners. It eliminates duplicate decoding efforts and reduces app and
> driver complexity, so actually the sliced interface would have become
> the main v4l2 vbi interface. Well, today I wonder if traditional Unix
> plumbing with standard DV stream formats, such as ETS 300 472 (DVB TTX),
> isn't better suited.
>
> Your idea sounds not completely off, which reasons against did you have
> in mind?
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.
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)
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.
Thoughts?
-- Peter
