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

[Johannes Stezenbach <js@linuxtv.org>]

On Tue, Sep 21, 2004 at 05:33:43PM +0000

  "Ain't it funny how time slips away..."

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

> 1) Scaling the video to the desired size (width/height of picture).
> 2) Positioning the video (scaled or unscaled).
> 3) Setting the presentation format (move this from video.h to say
> scaler.h).
> 4) Set the source to be from video decoder N.  This would work like the
> current video decoder set source ioctl where you pass the video scaler
> _device_ the fd of the required video decoder.
> 5) Means to set interlace/progressive output mode.
> 5) Get status of device (e.g. error reading the data from the video
> decoder's frame store/buffer).
> 6) Get capabilities.

The question is: Is there a need for another standard API?
Otherwise, maybe we could have a standard DVB scaler API, and
then have a generic DirectFB scaler driver.

> B) There is a need for a PIP device with such features as:
> 
> 1) Setting source of PIP e.g. from output of video decoder (using fd as
> handle).
> 2) Setting size of PIP output on screen (e.g. 1/2 or 1/4 scaling).
> 3) Setting position of PIP on display.
> 4) Setting size of border.
> 5) Setting colour of border.
> 6) Get status of device.
> 7) Get capabilities.

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

> 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 would recommend that we either change "vbi.h" to "denc.h" and add the
> extra functionality or create a new "denc.h" file that #include <vbi.h>.
> What do you think?
> 
> Also, looking at the "vbi.h" file you have the DVB_VBI_SET_SOURCE ioctl
> setting the source to be from the demux device.  This isn't always the
> case, as you could have the Teletext or WSS data fed from memory.

I think this is already supported by vbi.h (or at least it was on my
TODO list).


Regards,
Johannes