| Zapping · ZVBI | |
With "video4linux" drivers only one application at a time can capture VBI data. The 2nd generation "v4l2" API allows multiple clients to open a device, but still only one client may read from the device. If for example the Nxtvepg daemon runs in the background users will not be able to start a Teletext application. The VBI proxy was developed as a solution to this problem.
VBI can transport many independent data streams: VPS, WSS, Closed Caption and Teletext, within them PDC, XDS and custom data streams providing such services as Teletext, subtitles, caption, NexTView and other Electronic Programme Guides, channel identification, video recording triggers, information about the current program, wide screen signalling and more. We want to share one VBI stream between for example an application opening the device to update the system clock, Teletext viewers, TV viewers displaying channel names, caption or subtitles, recording applications, a PVR watching channels for recording triggers, and an EPG daemon updating its database.
The proxy must assign higher priority to recording and lower priority to background applications. It must coordinate channel changes between background "data harvesting" applications. Such apps would register a channel request with the proxy together with a priority and expected time of use and the proxy will then grant those requests according to priority and previous grants in a round-robin way.
The VBI proxy is implemented as a daemon zvbid, which
usually will be started during system boot. The daemon remains dormant
until the first proxy client connects through a socket, then opens the
VBI device and starts capturing and decoding the services requested by
the client, e.g. Teletext. It will not pass raw but sliced VBI data,
reducing the required bandwidth and saving repeated decoding of data
needed by multiple clients.
One drawback of this solution is that clients must be adapted, i.e. instead of opening the VBI device as usual, clients have to connect to the daemon (but if the daemon is not running they should fall back to using the device directly). For most applications already using libzvbi the change is minimal: A single function call is enough to create a proxy client and connect to the server, another to start capturing. The API to capture and decode services is identical for v4l2, v4l, bktr, dvb and proxy devices. Legacy applications can often be ported simply by replacing open and read system calls with their libzvbi equivalents.
As a work-around for applications which cannot be adapted, a wrapper zvbi-chains
is available which intercepts access to the VBI device and redirects it
to the proxy. In this case however only raw VBI data can be
forwarded, resulting in a significantly higher CPU load.
Hopefully the solution is elegant enough to convince the authors to invest the necessary effort to switch to libzvbi (or at least implement the proxy protocol) in subsequent releases of their software.
The proxy may still need improvement, see below for a detailed list of open points, but at least the basic service works well, and the API will remain backwards compatible. Some applications using the proxy:
proxy-test which can read and dump Teletext and VPS data from the proxy. Try -help for a list of options.
zvbi-chains <options> alevt
With proxy you can run these applications (or multiple instances of them, perhaps only pure VBI apps - YMMV) in parallel.
This is an unordered list of open points (unimplemented or yet undecided) regarding the proxy. Any comments or help appreciated.