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

* Multilingual subtitle recording (SAMI).
* Integrate XvPutImage controls into the tveng.c virtual control
  layer.
* libtv/cpu.c needs an SSE3 check.
* Capture buffer negotiation (tv_set_buffers) is only implemented for
  interfaces with buffer queue (i.e. v4l2).
* Fail if configure cannot find libzvbi, add --without-zvbi to override.
* Create a shadow list of controls in tveng.c instead of _ignore. 
* Disable overlay GUI if not possible (driver, DGA etc).
* Take a look at ATI video in Xorg CVS. 
* Add a shadow VBI switch to disable VBI on startup errors or --no-vbi
  for the _current session_.  Don't override the persistent user switch.
* Handle locked gconf.
* Investigate gtkglext.
* Middle mouse button shouldn't be hardwired but run a Python command.
* Prefs > Video: "Fullscreen screen 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.
* Mouse wheel needs testing.
* keyboard: there are too many conflicts between the Zapping
  and Xawtv mapping, better add an option to prefs.
* Suppress mute function of keypad enter when entering
  channel number.
* 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?
* Recording: like mixer volume, substitute tv card brightness and
  contrast control when available for XVPutImage.
* 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.
* Channel up/down should finish channel number entering
  on keypad or (a)lirc.
* 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.
* Check compilation works without optional libs
* Switching subtitles on/off needs improvement:
  Make widgets insensitive if we have no previous page
  and cannot lookup. Unselect and sensitive in
  Teletext mode.
* 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?

* 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. 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

  a) in picture
  b) below picture

  * Fixed width / proportional
  * Movable
  * Resizable

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

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
