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

[Johannes Stezenbach <js@linuxtv.org>]

Rob.McConnell@Zarlink.Com wrote:
> linux-dvb-bounce@linuxtv.org wrote on 05/10/2004 22:32:54:
> > 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.

DirectFB offers a consistent set of APIs for all screen output,
including scalers, OSD/graphics layers and hardware OSD regions;
it lets you blend and mix them and change stacking order; it has
software fallbacks for all common graphics operations and allows
you to plug in hw acceleration according to your hw's capabilities;
it can handle some aspects of video output encoder settings; it can
handle freetype fonts and load PNG and JPEG images; and it also
handles all user input devices. And DirectFB is modular so you
don't get bloat if you don't use e.g. freetype fonts.

Out of this, only the scaler belongs somehow to the DVB API.

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

V4L was written for PC/workstation framegrabber/analog-TV cards.
Certainly it has grown over the years, and we could "embrace and extend"
it for DVB -- but not in a timeframe any of us would be happy with.
I also doubt that would improve usability.

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

Well, IMHO if you want graphics output then you need a frame buffer
device. It's the Linux way.

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

I fear that this is true.

Regards,
Johannes