[linux-dvb] Re: Video output support for cards and STBs

[Johannes Stezenbach <js@linuxtv.org>]

Hi Dok and Rob!

Dok: I thought it might be a good idea to discuss this issue with you,
so I pointed Rob into your direction. However, it might be a good
idea to move this discussion to either the directfb-dev or linux-dvb
Mailing list.

Rob.McConnell@Zarlink.Com wrote:
> Now a DENC on a STB/iDTV can have some or all of these functions:
>
> 1) Ability to set the video standard for composite output (e.g. PAL
> B/G/H/I/M/N, NTSC-M/J, PAL-CN, SECAM, etc.)

Hm, I thought the PAL and NTSC variants differ only in the sound
carrier frequencies, so it is only relevant for modulated VHF/UHF output.
If so, it is not really appropriate to handle this in DirectFB, is it?

> 2) Ability to set the video output mode (e.g. RGB - with/without sync on
> green, component video - YUV, S-VHS - Y/C and composite - CVBS).

In Galaxis' current STBs this is handled via an external
AV-mux, controlled by a (trivial) proprietary API. But we
should maybe add a standardized API for it to DFB or DVB.

> 3) Ability to set scan mode (e.g. progressive or interlaced output).
> 4) Ability to enable different test pattern modes (e.g. colour bar, pluge).
> 5) Ability to choose it source from output of video decoder/scaler, REC-656
> input, OSD, OSD+video.
> 6) Ability to choose sync mode (master - it generates H/V signals, or slave
> - it sync to incoming H/V signals).

> 7) Ability to insert Teletext data into the VBI (e.g. WST-625, WST-525)
> 8) Ability to insert WSS data into the VBI (e.g. line 23 wide-screen
> signalling)
> 9) Ability to insert VPS data into the VBI (video programming signalling
> for VCRs and/or TVs).
> 10) Ability to insert CC data into the VBI (close caption data for US and
> European markets).
> 11) Ability to enable/disable Macrovision.
> 12) Ability to insert CGMS data into the VBI (copy generation management
> system) to prevent unauthorised copying of source material.
> 13) Ability to convey EDS data in the VBI (extended data services such as
> EPG).

All VBI stuff could trivially be added to the existing DVB VBI API.
IMHO DirectFB has nothing to do with it (it controls other
functions of the video output encoder).

> 14) Ability to filter luma and/or chroma paths.
> 
> __DISCUSSION POINTS__:
> There seems to be similar requirements for both STBs and graphic cards with
> no common API at the moment.  It would be silly to create an API solely for
> one camp without vision of the other.  Also, it would be a waste of
> time/resources if both camps duplicated the work to create a set of APIs to
> handle these requirements for themselves.
> 
> There are a few points that need raising:
> 
> A.  Do current STB/iDTV Linux folk use the DirectFB approach with their own
> hooks in for supporting DENCs?  If they don't use DirectFB, then do you
> have your own API that sets up the DENCs?  Wouldn't it be better to have a
> common API to provide this functionality?
> 
> B. Are the set of DENC requirements for STBs/iDTVs too specific to be of
> any use for gfx card folks?  OTOH, do gfx card folk have specific video
> output requirements that differ from STBs/iDTVs?
> 
> C.  Would it benefit the community to create an API that can be used by
> both graphics card folk and STB/iDTV bods without duplication of code?  For
> example, could we have a set of basic functions that the graphics card folk
> can use and the STB people can extend into their own "denc.h" api?

Currently the DirectFB drivers we use on Galaxis hardware are based
on a device driver which allows e.g. scaler and OSD control, with
an proprietary API. I am contemplating if it would make sense to
standardize parts of this API and add it to the DVB APIs. So we
could have a generic DirectFB video scaler driver on top of it.
However, I am not sure and I think it is up to Dok to decide.

An even more fundamental question: Should we even care about
supporting STBs which do not use DirectFB, or just say "sorry, Rob".

Regards,
Johannes