[linux-dvb] Re: video4linux converging with linux dvb

[Michael Hunold <hunold-ml@web.de>]

Hi,

On 29.09.2004 14:51, Rob.McConnell@Zarlink.Com wrote:
> I sent out a mail yesterday to the linux-dvb ML questioning the
> capabilities of the Linux DVB V4 API for supporting STB/iDTVs.  The current
> V4 API supports the frontend, demux and audio/video decoders quite well
> (even for STBs), but still lacks proper support for video scaling, video
> encoder (DENC) and other capabilities such as PiP.
True.

> Now I have only recently taken a peek at the V4L2 APIs and understand that
> they support video scaling/cropping and some video output capabilities.
AFAIK the video output or DENC functionality has never been used in any 
driver or application.

> However, there are requirements for video encoders (DENC) that don't appear
> in the API.  For example, there isn't the ability to specify RGB, YUV, YC
> (S-VHS), CVBS output configurations, enabling/disabling Macrovision,
> enabling certain test modes (e.g. colour bars), CGMS support, etc.  These
> are typical functions that DENCs provide as well as WSS, VPS, close
> captions and teletext insertion all in the VBI.   Now the Linux DVB V4 API
> has touched on the WSS, VPS and teletext issues, but I would have thought
> it better to have all this capability "packaged" together.
IMO these problems are completely bound to STBs.

On x86, you only have the full-featured cards where things are hidden 
behind the av7110 and are already addressed by the existing 
applications. In future design, mostly budget cards will be used and 
video output, video layer handling and video scaling are then completely 
up to the gfx processor. So I think everything up to the decoding level 
should be in the DVB API, when it comes to displaying things, it belongs 
somewhere else. But I admit that it's a matter of taste.

On STBs, however, things are different. There, you have everything 
bundled together, data transfers from the demux to the decoder and then 
to the DENC are mostly handled inside the

I agree that it's perhaps useful to have a plain-and-simple API for STBs 
that addresses these problems. Perhaps a "denc0" device that has support 
for common things found in STBs.

> Then there's the issue of video scaling.  The current Linux DVB V4 video
> API  I modified to allow the presentation format to set internal
> scaling/centre cut-out/letterbox modes that are usually integral to the
> MPEG video decoder hardware.  In the UK the end aspect ratio is dependent
> on the broadcast aspect ratio as well as transmitted AFDs (active format
> descriptors), but the user (or application) can override this to display a
> 1/4 or 1/16 or other-size video _underneath_ the graphics/OSD plane.  So,
> then there's the question of whether the Linux DVB V4 video API should be
> extended to handle scaling (especially for STB chips) or to use the
> V4L/V4L2 API.  It seems very disjoint to have 2 separate APIs, when the
> underlying hardware is closely coupled.
I think neither should be the case.

Traditionally, we've put the video layering, scaling and positioning 
into DirectFB. The benefit is that it is completely user-space based, so 
copyright problems can be avoided (think about Macrovision). IMO this is 
good, because all other gfx related things like accelerated drawing 
operations and layer handling are already handled by DirectFB.

There are some unsolvable things (I wouldn't call them problems) with 
that approach I admit. Some STBs like to switch aspect ratios on a 
per-frame basis. For example when the ratio is switched from 4:3 to 16:9 
between two programs, you won't see any distortions. Using DirectFB, the 
userspace application has to first read the aspect ratio changed event 
from the video decoder and then has the chance to change the aspect 
ratio of the video layer. In the time between, the picture may be distorted.

I don't think that it's useful to introduce V4L to STBs, it has too many 
unintersting things inside and the DENC api is nonfunctional at the moment.

I can't imagine a box without DirectFB anyway. Even the most simple 
boxes need to do some OSD and drawing stuff. Using proprietary code for 
that, but using the DVB V4 API on the other hand is -- sorry -- stupid.

> So the next logical question is should both camps start to think about
> collaborating together to form a single set of APIs that handle both
> analog/digital cards as well as STBs?  AFAIK, the Linux DVB API was a
> branch off from the V4L work a few years ago.  With both camps now looking
> at supporting digital cards/STBs then it would make sense to remove
> duplication of code and time.
I don't think that there is currently any code duplication. I agree that 
basic DENC support can be added to the V4 API to support STB platforms. 
On x86 this won't help because the DENC is part of the gfx adapter. 
There, it's already handled by DirectFB. For example with Matrox 
Dualhead adapters, the second head with the DENC is found as a separate 
screen:

Screen (01) Matrox CRTC2 Screen
   Caps: VSYNC ENCODERS OUTPUTS

   Encoder (0)  Type: TV
     Caps:         TV_STANDARDS
     TV Standards: PAL NTSC

   Output (0)
     Caps:       CONNECTORS SIGNAL_SEL CONNECTOR_SEL
     Connectors: SCART YC CVBS
     Signals:    YC CVBS RGB

     Layer (02) Matrox CRTC2 Layer
        Type: GRAPHICS VIDEO STILL_PICTURE
        Caps: SURFACE FLICKER_FILTERING BRIGHTNESS CONTRAST HUE
              SATURATION FIELD_PARITY

     Layer (03) Matrox CRTC2 Sub-Picture
        Type: GRAPHICS VIDEO STILL_PICTURE
        Caps: SURFACE OPACITY ALPHACHANNEL

> Any thoughts/comments?
If we put all things inside DirectFB, applications for both x86 and STBs 
will run without changes. If we put a separate DENC API to the V4 API, 
applications need to be aware of the differences.

> Rob : )
Perhaps we need some more discussion on this topic, let's hear what 
others think about it.

CU
Michael.