[linux-dvb] Re: Recommendations for new V4 APIs

[Rob.McConnell@Zarlink.Com]

Hi Johannes,

Back tracking a little here to add a few extra points.  Hope it doesn't
upset the mail thread....

js@linuxtv.org wrote on 05/10/2004 22:32:54:

> On Tue, Sep 21, 2004 at 05:33:43PM +0000
>
>   "Ain't it funny how time slips away..."
>
> Rob.McConnell@Zarlink.Com wrote:
> > C) There is a requirement for setting up the DENC output
characteristics.
> > The following functionality if required:
> >
> > 1) Setting the source of the DENC from the output of video scaler or
video
> > decoder device and/or OSD (using fd as handle).
> > 2) Setting the output format of the DENC to RGB, component YUV, S-video
> > (Y/C) and composite formats.
> > 3) Setting colour standard (PAL/NTSC/SECAM).
> > 4) Setting interlace or progressive scan output.
> > 5) WSS (we can simply include vbi.h)
> > 6) CGMS (copy generation management support).
> > 7) Macrovision support.
> > 8) Closed Captioning.
> > 9) VPS (from vbi.h)
> > 10) Teletext insertion into the vbi.
> > 11) Get capabilities.
>
> IMHO the mode setting and releated stuff belongs into the frame buffer
> driver (if you have one...). Additionally one needs an AV-MUX driver
> (which handles stuff like VCR outputs, pass-through from VCR input
> to the TV etc.). Currently there is no standard API, and it is debatable
> wheter a) we could come up with a standard, and b) if it belongs
> to the DVB API. The one reason to have a vbi.h in the DVB API is
> that is common to push vbi data from the demux directly to the
> output encoder. The other VBI releated stuff could be added there
> trivially, however I'm not sure if ot really belongs there
> (maybe we'd get flamed by framebuffer people who think the
> video output encoder belongs to the frame buffer driver).

I've been looking at some other manufacturer's DENC devices and found that
some actually take a REC-656 input with the WSS, CC, TTX data encoded in
the ancillary region.  This means that the vbi devices set source should
not necessarily be from a demux, but rather from the output of a rec-656
encoder.  It begs the question as to where should a rec-656 decoder (input
to STB) and rec-656 encoder (output) exist in the DVB API, if at all?

I am currently knocking up a denc.h file that should help show what a
typical denc can/cannot do.  Maybe this will help to decide whether we
should have a separate denc device (IMHO I think we should) or try and
cobble it together in the framebuffer/DirectFB/V4L/whatever.

Rob : )