Outstanding issues for future releases
--------------------------------------

* Option to mute if the video window is invisible?
* http://www.geocities.com/beinges/index_nofla.htm
* Recording won't work while the --esd-out audio loopback is active.
  Also bilingual recording (with monaural to speakers) isn't
  implemented yet.
* Muting the audio loopback clicks. Try fade out the volume.
* Integrate XvPutImage controls into the tveng.c virtual control
  layer. Like mixer volume, substitute tv card brightness and
  contrast control when available for XVPutImage.
* Capture buffer negotiation (tv_set_buffers) is only implemented for
  interfaces with buffer queue (i.e. v4l2).
* Disable overlay GUI if not possible (driver, DGA etc).
* Take a look at ATI video in Xorg CVS. 
* Handle locked gconf.
* Investigate gtkglext.
* Middle mouse button shouldn't be hardwired but run a Python command.
* Prefs > Video: "Fullscreen display resolution" might be a better name.
* Fullscreen should always fill the visible screen, even if "no
  change" of resolution has been selected. Additionally Zapping should
  monitor the resolution and adjust dynamically, in case the user
  switches with NK+/- or randr (background display mode!). Holy Jebus
  all the work and few will ever notice...
* With the new Teletext plugin interface it would be trivial
  to create a split display showing 2, 4, 9, ... pages at
  once and with a little more effort split video/teletext,
  usefull in fullscreen. Would be nice if we could combine
  that with multiple cards, channel mosaic and picture-in-
  picture. Even better with OpenGL animations.
* keyboard: there are too many conflicts between the Zapping
  and Xawtv mapping, better add an option to prefs.
* Xawtv import considers ~/.xawtv but not /etc/X11/xawtvrc, see
  man xawtvrc.
* Examine interaction with change display from gtk-demo.
* Widget indentation needs improvement, use
  gtk_alignment_set_padding() (gtk 2.4).
* tv_set_overlay_buffer: Check DGA presence before calling
  zsfb. Test with Xnest.
* Keyboard preferences: Python commands should not be visible,
  by default. Use GtkAction?
* Examine interaction of Zapping (esp. overlay) with RANDR.
  http://keithp.com/~keithp/talks/randr/randr/
  xc/doc/specs/Randr, xrandr et al
* After "add all channels" in the channel editor Zapping
  should scan for station names.
* UYVY in mpeg plugin.
* Prefs building takes longer and longer, it's annoying.
* Maybe Zapping should support all xawtv command line options?
* We need an Xv overlay port menu.
* http://developer.gnome.org/dotplan/porting/ checklist.
* Are we using window fully visible, partially visible and
  fully obscured X11 events to optimize capture mode?
  Apparently not. See overlay.c.
* preferences from context menu (zapping-misc 2003-01-05)
* configure.in: esd, oss etc checks
* Improve documentation.
* vbi: add toggle button to disable CC/TTX decoding
  (independent of station name decoding, that is). Mind
  listing subtitles. Should also disable trigger
  decoding when all set to ignore.
* zapzilla: channel selector, properties.
* Get thumbnails of all tuned channels.
* PIP?
* Take TTX out of the context menus when Zapping doesn't
  receive TTX. (event timestamps?)
* Better audio mode (mono/stereo etc) support.
* Check tveng has frame rate for timestamping. (Unlike mpeg bug.)
* Remove default overlay page?
* More compression formats.
* Trigger: Close should remember it had been clicked already
  when a trigger is merely repeated.
* Recording schedule.
* Screenshot plugin: subtitle overlay
* Mpeg plugin/mp1e very low frame rate interrupts display,
  probably a scheduling issue. Investigate if/how this can be avoided.
* Examine the possiblity of linking movie titles, VBI plugin API.
* Deinterlace plugin.
* VBI station name ignored when card w/tuner & composite selected
* Compress config file (libxml).
* Config toolbar using Iaki's dnd code.
  Update: libegg contains a new toolbar widget apparently supporting
  user toolbar configuration. Update: see gtk+ 2.4.
* Clean up context menu.
* Remove tveng_frame_format.bytesperline. (Um, why?)
* Verify all Gnome etc URLs everywhere.
* Proper error messages on xawtv import.
* In overlay.c, possibly elsewhere, we request GDK events but never
  disable. Can we safely, without disabling events enabled before
  or between, by other zapping/gnome/gtk/gdk modules?
* WM_ICON could display a network icon in titlebar?

* Switching subtitles on/off needs improvement:

  On a channel change, make subtitle widgets insensitive if this
  channel has no default subtitle page remembered from an earlier
  activation and/or we do not currently receive subtitles
  (zvbi_find_subtitle_page ()). Listen to VBI3_EVENT_PAGE_TYPE to
  make the widgets sensitive when that changes. Always make the
  widget sensitive in Teletext mode. Add a subtitle menu to the
  video window main menu (currently only a context menu).

* Open subtitles:

  This is mainly interesting for subtitle recording and alpha blending
  (although I would prefer window compositing or OpenGL textures for
   positioning flexibility). For a starting point see SubtitleView->
  get_image, currently used for screenshots. YUV alpha blending
  formula:
  Y  = Y2  * a + Y1  * (1 - a);
  Cb = Cb2 * a + Cb1 * (1 - a);
  Cr = Cr2 * a + Cr1 * (1 - a);
  Seems wrong but converting to RGB, alpha blending and converting
  back to YUV would give the same result.

* Multilingual subtitle recording:

  With "closed" caption/subtitles this is easy, see also
  libzvbi/test/ttxfilter. To create multilingual subtitle files: a) open
  a file for each language, or b) store multiple languages in the same
  file (e.g. SAMI). It will probably suffice to call the zvbi export
  module with different vbi_page.pgnos and handle the details there.
  We may have to know all pgnos before creating the file header though.

* Parrot plugin:

  Zapping stores the last few seconds of captured, uncompressed video
  in RAM. Needs much memory but no CPU. If something interesting
  happens one can reverse, take a screenshot or start recording.
  Some work has been done, but it's not that simple to integrate into
  the capture fifo. It's lower priority, the code needs a major
  update, if not a rewrite.

* Capture pixel formats and conversion:

  Various functions in capture.c are intendend to find the best
  capture format and minimize the number of conversions required, for
  example by reference counting converted copies of image buffers in
  the capture fifo.

  One function in particular, request_capture_format_real, given
  a set of target formats tries to find a source format, where a) the
  format is supported by the driver, b) we have functions to convert
  to all target formats and c) we need the fewest conversions, eg. one
  target equals source. It fails to consider a few other important points:

  * Lossy YUV <-> RGB conversion. The native format of most video
    capture devices is YUV 4:2:2. Requesting RGB, with conversion in
    hardware, or worse in software by the driver, will incur rounding
    errors. This may be undesirable if one of the target formats uses
    YUV color space. Under strange circumstances the function may even
    attempt to convert from Y8 to RGB24, instead of choosing an RGB
    source format.
  * Lossy conversion of lower to higher color depth, eg. RGB15 to
    RGB32, which is undesirable eg. for screenshots.
  * Lossy conversion from lower to higher density planar formats,
    eg. YUV 4:1:0 to YUV 4:2:0.
  * Conversion costs, in CPU cycles and memory bandwidth, are not
    considered. For example RGB24 to RGB15, RGB24 and BGR24 is cheaper
    than RGB15 to RGB15, RGB24 and BGR24. It also depends if we have
    a C or MMX converter, and on the image size due to limited CPU
    cache.
  * XVideo display can convert on the fly without costs, except in a
    few cases byte reordering YUV 4:2:0 to 4:2:2. Memory bandwidth
    is still significant.
  * Planar YUV can be converted to YVU and vice versa by pointer
    swapping.
  * Transient format requests, eg. to take a screenshot, cause two
    source format switches and thereby frame loss. In some cases the
    driver may pass a broken image. Conversion of images already in
    the fifo may be impossible. It would be better to accept a
    suboptimal source, and/or to keep the source format instead of
    falling back to a slightly more efficient one immediately.

* Better 16:9 support:

  WSS acquisition needs to be more robust. Usually video and VBI
  capturing cannot overlap and video capturing includes the WSS
  line. Hardware (sliced) VBI decoding would pick it up despite video
  capturing, but not every hardware has the capability and AFAIK no
  driver supports the API yet. We can still sample the signal off
  captured images or even overlaid images by reading from video ram.

  To get rid of the annoying WSS and CG patterns in the picture, in
  overlay mode V4L2 cropping could reduce the image height, then the
  driver could shift the VBI capture window down to cover the WSS. If
  that's not possible one could still clip the line out, but then
  Zapping won't see WSS changes either. In capture mode reducing the
  height may conflict with recording (height mod 16 et al). Blanking
  the line after extracting WSS should be no problem.

  The appearance menu is editable now, nevertheless it must be
  possible to switch between 4:3 and 16:9 regardless of the current
  window size. I'd also like two 16:9 modes, one properly scaling
  anamorphic 16:9 and another to get rid of letterbox bars. Would be
  useful for proud owners of 16:9 monitors and generally save screen
  space.

  Overlay is usually limited to 768. Xv could overlay with bounce
  buffers in video ram, but right now doesn't (or does it?). Zapping
  should automagically fall back to capture mode to achieve
  1024x576. As a last resort it can scale to 768x432. Better yet it
  had a deinterlace plugin which can optionally scale 1024:768. We
  could use capture mode with field motion (50/60 Hz refresh rate) and
  compensate for filterless hw scaling. Just duplicating every third
  pixel already gives artefacts, not to mention dropping one of four
  field lines.

  Fullscreen mode currently implies overlay and the picture aspect is
  assumed 4:3. Actually the app should look up an XF86 Modeline with
  16:9 aspect or use e.g. 1024x768, kind of a HDTV letterbox.

* An external frequency table table would be nice. Would be easier to
  update, even remotely (libxml2 nanohttp). Possible file format:

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE frequency_tables [
      <!ELEMENT frequency_tables (table+)>
      <!ELEMENT table (name,domain?,country+,videostandard+,range+)>

      <!ELEMENT name (#PCDATA)
        -- table name for configuration file: (0-9|a-z|A-Z|_)+ -->
      <!ELEMENT domain (#PCDATA)
        -- distinguish tables used in same country, for user -->
      <!ELEMENT country (#PCDATA)
        -- country using this table: RFC 1766 / ISO 3166 alpha-2 -->
      <!ELEMENT videostandard (#PCDATA)
        -- video standard used with this table:
           PAL_B | PAL_B1 | PAL_G | PAL_H | PAL_I | PAL_D | PAL_D1 |
           PAL_K | PAL_M | PAL_N | PAL_NC | NTSC_M | NTSC_M_JP | SECAM_B |
           SECAM_D | SECAM_G | SECAM_H | SECAM_K | SECAM_K1 | SECAM_L -->
      <!ELEMENT range (prefix,first,last?,frequency,bandwidth)>
      <!ELEMENT first (#PCDATA)
        -- name of first channel in range, optional prefix and
           decimal or alphabetic index: (a-z|A-Z)*((0-9)+|a-z|A-Z) -->
      <!ELEMENT last (#PCDATA)
        -- name of last channel in range, same syntax as first,
           can be omitted if first and last are identical -->
      <!ELEMENT frequency (#PCDATA)
         -- video carrier frequency of first channel in range, Hz -->
      <!ELEMENT bandwidth (#PCDATA)
         -- channel distance in Hz -->
      <!ENTITY %context "context (qtvision|xawtv|zapping) #IMPLIED"
         -- element is specific to this application -->
      <!ATTLIST name %context;>
      <!ATTLIST range %context;>
      <!ATTLIST domain xml:lang NMTOKEN "en">
      <!ENTITY ccir_uhf "<range...>">
    ]>
    <frequency_tables>
     <table>
      <name>foobar</name>
      <name context="xawtv">foofoo</name>
      <domain xml:lang="fr">cable</domain>
      <country>US</country>
      <country>CA</country>
      <videostandard>NTSC_M</videostandard>
      <range>
       <first>SE1</first><last>SE10</last>
       <frequency>55250000</frequency>
       <bandwidth>6000000</bandwidth>
      </range>
      &ccir_uhf;
     </table>
    </frequency_tables>

  Some notes. Country identifies the country or countries using the
  table. The user is supposed to choose by country and domain, for
  example US and "Cable HRC" may be listed in the UI as "United
  States Cable HRC", or DE and no domain simply as "Deutschland".
  This will require a locale library to translate country names. If
  the application already knows the country the user is in it can
  easily pick a default. Likewise videostandard provides a
  default.

  Range is a continuous run of channels instead of listing channels
  separately to save space and typing. First and last are the channel
  names. Enumerating channels will require a moderately intelligent
  alphanumeric counting function: "9" -> "10", "99" -> "100", "S9" ->
  "S10", "S99" -> "S100", "S001" -> "S010", "S099" -> "S100", "A" ->
  "B", "Z" -> oops.

  Elements can have attributes to distinguish context, for example the
  table name as used in various imported config files, or ranges
  identified as incorrect but listed for compatibility.

* Caption below picture:

  When the video is letterboxed and there are no open subtitles in
  the black bars (see WSS625) move the video up. Otherwise, in window
  mode add a black bar below the video and move the subtitle view down.
  In fullscreen mode make the video smaller than the screen (if it
  isn't already) and move it up, the subtitle view down.

* Custom caption/subtitle fonts.

* Support for Multiple Devices:

  Step 1: Write code to determine if the XVideo-V4L wrapper is available
    on the current display.

    One a second thought this seems unnecessary.

  Step 2: Write code which, given a V4L or V4L2 device file name, finds
    the corresponding XVideo-V4L port number. XVideo-V4L won't tell which
    kernel device it opened, but they will share properties such as the
    values of controls. V4L devices may permit only a single open, and
    XVideo-V4L may reset properties at open, complicating things.

    DONE.

  Step 2a: Add new tveng.c function to changed the "controller".
    Fall back to attach if necessary, or let tveng1/25.c do it.
    Replace attach calls.

    DONE. In tveng_attach_device(), not with a new function. Rethink
    this when we get a standard init()/destroy() interface.

  Step 3: The tveng1.c and tveng25.c modules or tveng.c shall forward
    overlay requests to XVideo-V4L if available, otherwise access the
    kernel driver directly, so layers above tveng.c need not know
    about XVideo-V4L and change devices when switching between capture
    and overlay mode. Also solve the complications noted above.

    DONE.

    Some drivers (e.g. graphic cards with on-board video) can
    V4L2-capture and XVideo-overlay at the same time, at full frame
    rate. How can we take advantage of this?

    XXX drivers with kernel and xvideo interface need testing.

  Step 4: Write code finding all kernel video devices and all XVideo
    video devices similar to tv_mixer_scan().

    DONE.

  Step 5: Rewrite the video device preferences. Remove the pointless
    video input tabs, device capabilities and capture size displays.
    Add radio buttons:
     * No video display and recording, if that makes any sense.
     * Kernel video device (V4L, V4L2, BKTR, DVB)
       - Show a card and driver name as in the audio device prefs.
       - Ask for a video device file name as there.
       - Ask for a tuner device file name (BKTR) as there. Show
         this widget only on *BSD.
       - Option: use the XVideo-V4L wrapper or V4L/V4L2 DMA?
       - Option: use the V4L, V4L2 or BKTR API (for tests)?
     * XVideo device
       - Show a card and driver name?
       - Ask for a port number, from a menu if more than one is available.
       Note this is intended for genuine XVideo devices, not the V4L
       wrapper, although the user can select XVideo-V4L instead of the
       corresponding kernel device. To complicate things again, XVideo
       devices may work only on one screen in a Xinerama setup.
     * Emulator (for tests)

  Step 6a: Move the video, audio and VBI preferences into a separate
    dialog Preferences > Devices. The combined device preferences shall
    henceforth be known as a Virtual TV Device.

  Step 6b: Create a new configuration file ~/.zapping/devices.xml as
    outlined below and the respective code. Write code converting the
    zapping.conf device parameters to the new format and add one VTVD
    for each video input. Name them something like:
      <video-card-name> <video-input-name>

  Step 6c: Extend the Devices dialog to permit the creation of multiple
    named VTVDs. Similar to the audio mixer preferences, add a video input
    menu to the video device preferences. (XXX What about audio inputs
    as in BKTR?) This will allow VTVDs like:
      /dev/video0 tuner      + /dev/pcm0 soundcard + /dev/mixer0 video-in
      /dev/video0 composite1 + /dev/pcm0 soundcard + /dev/mixer0 line-in
      /dev/video1 tuner      + /dev/pcm1 tuner
      /dev/video2 tuner      + /dev/pcm2 tuner

  Step 6d: Replace the channel list video input parameter by a VTVD ID.
    Replace "any" by the first video input (usually tuner). Replace
    "any" video standard by the video standard of the tuner, or if
    ambiguous of the country, or if undefined the first standard.

    That "any" stuff sucks. I want to know precisely where the images
    come from, and how. Write code to find the VTVD and channel from
    individual parameters. Useful when Zapping is configured to not
    save parameters across quit/restart and see below.

  Step 6e: Either get rid of the video input, audio input and video
    standard items in the channel menu, or add a "magic" channel which
    can be changed this way and does not appear in the channel editor.
    It's unacceptable to say, change to channel 5, then to composite
    but internally we still point to channel 5, with channel names in
    the GUI and all.

  Step 7a: Create a new configuration file ~/.zapping/channels.xml as
    outlined below and the respective code. Write code converting the
    zapping.conf channel parameters to the new format.

  Step 7b: Rewrite the channel editor along HIG-2.
    * A channel list row shall contain:
      0: Channel number 0 ... n
      1: User channel name
      2: Virtual TV devices, a check-item menu. Purpose is to name all
         VTVDs which can tune in this channel.

         A VTVD set will permit
         a) Multi program recording when
            - each tv card has its own audio ADC
            - each tv card has a loopback to a different AC97 soundcard
            - mixed cases.
	 b) Watch and record using the same configurations, except
	    devices to watch video need no video or audio capturing
	    capability (e.g. XVideo). With AC97 one can record from one
	    audio input and route another to line out.
	 c) Background VBI acquisition (VPS, PDC, XDS, TTX, EPG) from
	    another channel, fast channel mosaic, live PIP which
	    requires video/VBI capturing but no audio output.

	 Write code to determine if VTVDs share required resources
	 and thus cannot operate in parallel.

      3: If VTVD video input is composite:
	  - Nothing
	 If terrestrial tuner:
	  - RF channel name and frequency
	 If satellite tuner:
	  - Longitude, frequency, polarisation etc
	 A symbol may be useful, e.g. plug, antenna, sat
      4: If VTVD is digital:
	  - PID (number field)
	 If VTVD is analog:
	  - video standard (combo box)
      XXX audio inputs? perhaps sat audio subcarriers left/right
        or DVB audio channel?
      5: Accelerator

    * Use DnD instead of Up/Down.
    * Allow channel name editing in the table.
    * Remove Edit channel: Name, Video input, Video standard.
    * Replace Edit channel: Accelerator by "type a new" as in
      Preferences > General > Keyboard.
    * XXX What shall we do with the frequency stuff?
    * Remove the OK button, changes shall auto-apply. Expect
      references to channels, e.g. from a recording
      schedule. Obviously we don't want dangling channel references,
      or even worse, change the channel being referred to.
    * Use window menu instead of "all channels" etc buttons.

Possible XML Device Table

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE device_table [
  <!ELEMENT tv-device (video-capture,audio-capture,audio-mixer,audio-output,vbi-capture)>
  <!ATTLIST tv-device id ID #REQUIRED -- Unique ID. The channel table
    shall refer to devices by this ID. -->

  <!ELEMENT video-capture (video-device-file?,tuner-device-file?,xv-port?)>
  <!ATTLIST video-capture api (v4l|v4l2|xvideo|bktr) #REQUIRED>

  <!ELEMENT audio-capture (pcm-device-file?)>
  <!ATTLIST audio-capture api (none|arts|esd|oss|alsa) #REQUIRED>

  <!ELEMENT audio-mixer (mixer-device-file?,mixer-input?)>
  <!ATTLIST audio-mixer api (none|oss|alsa) #REQUIRED>

  <!ELEMENT audio-output (pcm-device-file?)>
  <!ATTLIST audio-output api (none|arts|esd|oss|alsa) #REQUIRED>

  <!ELEMENT vbi-capture (vbi-device-file?,vbi-pes-file?)>
  <!ATTLIST vbi-capture api (v4l|v4l2|bktr) #REQUIRED>
]>

Possible XML Channel Table

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE channel_table [
  <!ELEMENT channel (refcount?,position?,name?,device+,
    (terrestrial|satellite)?,pid?,video-standard?,accelerator?,
    network?,subtitle-pgno?,teletext-encoding*,control*)
    -- One (of multiple) channel(s). -->
  <!ATTLIST channel id ID #REQUIRED>
    -- Unique ID, preserved when renumbering or renaming channels. -->
  <!ATTLIST channel refcount #PCDATA "0"
    -- References to this channel, e.g. from recording schedule,
       a decimal number. XXX rethink. -->
  <!ELEMENT position (#PCDATA)
    -- Position 0 ... n in channel list, a decimal number. Gaps are
       allowed but duplicates are not. Order of channels in the XML
       file is undefined. Channels without position number are not
       listed in the UI. -->
  <!ELEMENT name (#PCDATA)
    -- User channel name, UTF-8. Can be omitted, then Zapping will
       dynamically determine a name (from the device, frequency or
       network table). -->
  <!ELEMENT device (#PCDATA)
    -- ID of a Virtual TV Device (*or devices*) which can tune in this
       channel. -->
  <!ELEMENT terrestrial (frequency-table,frequency)
    -- Terrestrial reception parameters, if VTVD video input is a tuner. -->
  <!ELEMENT frequency-table (#PCDATA)
    -- Frequency taken from this frequency-table (table id). -->
  <!ELEMENT frequency (#PCDATA)
    -- Tuner frequency in Hz, a decimal number between 0 ... 2^32-1. -->
  <!ELEMENT satellite (longitude,frequency,polarisation)
    -- Satellite reception parameters, if VTVD video input is a satellite
       tuner. More details TBD. -->
  <!ELEMENT longitude (#PCDATA)
    -- Real number of degrees longitude east (e.g. Astra 19.2). -->
  <!ELEMENT polarisation (#PCDATA)
    -- Satellite tuner polarisation. TBD. -->
  <!ELEMENT pid (#PCDATA)
    -- DVB receivers only. TBD. -->
  <!ELEMENT video-standard (#PCDATA)
    -- Analog receivers only. Valid values:
       PAL_B | PAL_B1 | PAL_G | PAL_H | PAL_I | PAL_D | PAL_D1 |
       PAL_K | PAL_M | PAL_N | PAL_NC | NTSC_M | NTSC_M_JP | SECAM_B |
       SECAM_D | SECAM_G | SECAM_H | SECAM_K | SECAM_K1 | SECAM_L
       TBD. See also XML frequency table. -->

  <!ELEMENT accelerator (key,qualifier?)>
  <!-- XXX see if there's a Gnome standard. -->
  <!ELEMENT key (#PCDATA)>
  <!ELEMENT qualifier (#PCDATA)>

  <!ELEMENT network (call-sign|cni-8301|cni-8302|cni-pdc-b|cni-vps)+
    -- Network identifier, see also Libzvbi Networks Table DTD 1.0 -->
  <!ELEMENT call-sign (#PCDATA)
    -- ASCII. -->
  <!ELEMENT cni-8301 (#PCDATA)
    -- 4 digit Teletext packet 8/30 format 1 CNI: 0x([0-9]|[a-f]|[A-F])+,
       cccc cccc nnnn nnnn in binary. -->
  <!ELEMENT cni-8302 (#PCDATA)
    -- 4 digit Teletext packet 8/30 format 2 CNI: 0x([0-9]|[a-f]|[A-F])+,
       cccc cccc nnnn nnnn. -->
  <!ELEMENT cni-pdc-a (#PCDATA)
    -- 5 digit PDC Method A CNI:
       0x([0-9]|[a-f]|[A-F])([0-9]|[a-f]|[A-F])[0-9][0-9][0-9],
       cccc cccc nnnn nnnn nnnn. (This is a hex/bcd number.) -->
  <!ELEMENT cni-pdc-b (#PCDATA)
    -- 4 digit PDC Method B CNI: 0x3([0-9]|[a-f]|[A-F])+,
       0011 cccc nnnn nnnn. -->
  <!ELEMENT cni-vps (#PCDATA)
    -- 3 digit VPS CNI: 0x([0-9]|[a-f]|[A-F])+, cccc nnnn nnnn. -->

  <!ELEMENT subtitle-pgno (#PCDATA)
    -- Default subtitle page, either [1-8] (CC channels) or
       [1-8][0-9][0-9] (Teletext pages). -->

  <!ELEMENT ttx-encoding (pgno,charset-code)>
  <!ELEMENT pgno (#PCDATA)
    -- Teletext page: [1-8][0-9][0-9]. No duplicate ttx-encoding/pgnos.
       Order of channels in the XML file is undefined. -->
  <!ELEMENT charset-code (#PCDATA)
    -- A number 0 ... 127 or 0x0 ... 0x7F, see
       libzvbi/lang.h vbi_charset_code. -->  

  <!ELEMENT controls (TBD) -- XXX what if multiple VTVDs can tune this
    channel but have different control ranges? XXX we may end up with
    three controls levels: global, per VTVD, per channel. Perhaps one
    with absolute values, two with offsets/scale factors? What about
    controls present on only some VTVDs? -->
]>

* Audio device preferences idea:

  ( ) Use a software audio loop (recommended):
    Record audio from:
      ( ) TV card or soundcard PCM device (TV card device recommended
					   if the TV card can record audio):
        [/dev/dsp]
      [ ] Select this input when recording from a soundcard:
        [/dev/mixer]
        [line|v]
    Play audio through:
      ( ) ESD (recommended)
      ( ) ARTS
      ( ) Soundcard PCM device
        [/dev/dsp]
      XXX or
      ( ) ESD (required because Zapping runs on a remote computer)
      ( ) ARTS -- unsensitive
      ( ) Soundcard PCM device -- unsensitive

  ( ) Use an audio cable from the TV card or an external source to the
      soundcard:
    Record audio from:
      ( ) TV card or soundcard PCM device (TV card device recommended
					   if the TV card can record audio):
        [/dev/dsp]
      ( ) ESD
      ( ) ARTS
      ( ) No audio recording
    [ ] Control the playback volume with the soundcard mixer and
        select this input when recording from a soundcard (recommended):
      [/dev/mixer]
      [line|v]
    XXX or
    [ ] Select this input when recording from a soundcard, and mute
        it because Zapping runs on a remote computer (recommended):
      [/dev/mixer]
      [line|v]
  
  ( ) No audio

------------------------------------------------------------------------------

Please tell me about anything you think is worth adding:

    http://sourceforge.net/tracker/?func=add&group_id=2599&atid=352599
or  mailto:zapping-misc@lists.sourceforge.net