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

[Johannes Stezenbach <js@linuxtv.org>]

Rob.McConnell@Zarlink.Com wrote:
> Johannes Stezenbach <js@linuxtv.org> wrote on 05/10/2004 22:07:41:
> > 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?
> 
> Well, take NTSC M/J for example.  The difference here is the black level.
> If we start to look at the different flavours of PAL (B/G/H/N/M/CN/I) then
> the differences lie in the chroma sub-carrier frequency as well as the
> video bandwidth.  Then if you look at NTSC/PAL you see that there a
> different number of lines in the signal (525/625).

OK. The way I see it, PAL/NTSC/SECAM are certainly different modes,
and mode setting is handled in fbdev.
There must be a way to chose the PAL/NTSC variant in the DENC, though.

> > > 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.
> 
> True.  If a DENC can output multiple video "flavours" (RGB, Y/C, CVBS)
> simultaneously, then you need some mux to select the one you want to output
> on say SCART1.  However, if you say that we have N virtual DENCs where each
> one can provide a single video output signal (with the ability to set the
> output mode), then this would solve this problem.  Also, it would be akin
> to how we have multiple frontend devices and virtual demux devices in the
> Linux DVB V4 API.

I see.

> > An even more fundamental question: Should we even care about
> > supporting STBs which do not use DirectFB, or just say "sorry, Rob".
> 
> That goes against the freedom of using open source software and allowing
> the "user" to decide (rightly or wrongly) what s/w he/she wants to use.
> ;^)

Well, this discussion is about creating a "standard" API. There will always
be a limit where we cannot agree on a common way of doing things.

Ultimately having a common driver API means it will be easier to
port middleware and applications to different platforms. So if you
look at your application and middleware code you will see that
most of it (besides user interface cruft) is about service lists
and tuning, setting up demux, decoders and scaler, and SI/PSI handling.
There is relatively little code which takes care of mode selection,
encoder settings etc.  So my philosophy is that the DVB API should
concentrate on the important stuff and try to find a common API that
works for all, and exclude less important stuff where everyone is better
off using either prorietary APIs, or other exisiting Linux APIs.

That said, it still might be a good idea to have scaler and DENC stuff
in the DVB API. I don't know yet.


Regards,
Johannes