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

[Rob.McConnell@Zarlink.Com]

linux-dvb-bounce@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..."

Wow - "it'll soon be Xmas!"!

>
> Rob.McConnell@Zarlink.Com wrote:
> > A) Our hardware has separate blocks for video decoding and video
scaling.
> > The current V4 "video.h" header file does not contain any video scaling
or
> > PIP support.  It only has the addition of my last change for setting
the
> > presentation format.  In addition to this ioctl, we need the ability to
set
> > the size and position of the decoded video (e.g. quarter screen).  As
not
> > all STBs will be using DirectFB, I would like to propose a new video
scaler
> > API that allows such features as:
>
> IMHO all STBs should use DirectFB ;-)

I think we should draw up a technical list of pros/cons of DirectFB so that
we all get a picture of what it can/cannot do for all DTV devices out there
(STBs/iDTVs/cards/etc.).  None of this marketing hype thank you, just plain
technical reasons why using this over a standard DVB scaling API would make
sense.

Also, there seems to be overlap between V4L/V4L2 and DirectFB in terms of
scaling/video output.  One could argue that why did this happen?  Is it
better to have a scaling API that fits into the way we do things in Linux
DVB (source->sink approach using fds)?

> Why is PIP different from the normal scaler? I.e. you just have
> two scaler devices (possibly with different caps).

Yup, it could be done this way.  ;^)

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

If you're not using a fbdev, then is it simply tough?  Forcing someone to
use a fbdev just to get denc functionality doesn't make sense.  The s/w
arch should be flexible enough for someone to choose what components make
up a system.  It may be better to feed these requirements into the V4L/V4L2
and DFB APIs as well as having a new stand-alone denc api.  The new API
could then follow the adoption of how the other devices in the Linux DVB
system connect together (you could have virtual denc devices as well).

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

This may be quite complicated to knock up as it would have to satisfy STBs,
iDTVs, media-centres, PC cards each with their own requirements.  AV-mux
can be quite a tricky area to get right especially with the plethora of
equipment out there.

Rob ; )