[linux-dvb] Re: More V4 Video API Q's

[Marcus Metzler <mocm@mocm.de>]

>>>>> "Rob" == Rob McConnell <Rob.McConnell@Zarlink.Com> writes:

    Rob> Hi Marcus,

    Rob> I haven't been ignoring you, but have been trying to get my
    Rob> head around the V4L2 spec and how maybe we could use it on
    Rob> STB products.

    Rob> First of all, do you know whether anyone out there actually
    Rob> uses the V4L2 spec for STB hardware?

    Rob> Marcus Metzler <mocm@mocm.de> wrote on 27/09/2004 15:39:26:

    >> >>>>> "Rob" == Rob McConnell <Rob.McConnell@Zarlink.Com>
    >> writes:
    >> 
    Rob> Hi Folks,
    >>
    Rob> Been looking at the video driver a bit more and have the
    Rob> following points to make:
    >>
    Rob> 1) Most STB hardware has a video decoder and video scaler
    Rob> (either in one block or two).  Now, the current V4 API
    Rob> doesn't handle requests to size the screen to say 1/4 size,
    Rob> or 1/16 size or 2x size _and_ to position it.  I think we
    Rob> should add these to the existing video.h header file and add
    Rob> a capabilities flag to check whether the underlying hardware
    Rob> can scale and position the video.  This would be preferred
    Rob> over having a separate video scaler API and device node.
    >>
    Rob> Could we extend dvb_video_presentation_format?
    >> That is usually handled by the v4l1/2 API.

    Rob> Now I'm not sure what type of V4L device we should use for
    Rob> this (capture, overlay, output, ...) and also do we want to
    Rob> deviate from the source->sink approach of connecting devices
    Rob> up in the V4 API?  Currently, we can set the source of the
    Rob> video decoder to be from a demux fd, but there's no similar
    Rob> method of connecting a video fd to a V4L2 device, or is
    Rob> there?

    Rob> Also, looking at the V4L2 0.7 API it seems that the /dev/vout
    Rob> device is still WIP in terms of assigning minor numbers, etc.
    Rob> Is this really the case?

    Rob> Then there's the story of the video encoder (DENC).  AFAICT,
    Rob> the V4L/V4L2 API doesn't support things like
    Rob> enabling/disabling Macrovision, CGMS enabling/disabling and
    Rob> turning on/off test patterns (e.g. colour bars). If it can,
    Rob> then maybe it might be worth using this API.  However, I
    Rob> think it might just be as simple to knock up a denc.h V4 API
    Rob> that incorporates video output encoder features as well as
    Rob> including the vbi.h file for WSS/VPS/TTX insertion into the
    Rob> VBI.

    Rob> I think the _real_ question is how close are the V4L2 and
    Rob> Linux DVB APIs and are they starting to merge?  Would it be
    Rob> better to have a "self-contained" set of Linux DVB APIs that
    Rob> handle most STB h/w requirements (as well as cards) or should
    Rob> there be some cross-pollination going on?

I think the same question came up on the v4l list. The overlap between
DVB and v4l is in decoder hardware (including overlay) and frontends
(which would be analog TV tuners and hardware encoders). Before Nokia
started with the DVB API, the DVB stuff was already based on v4l, but
got changed subsequently. AFAIK, STBs like Tivo (i.e. analog receiver
with hardware/software encoder) are partly based on v4l2, but I
haven't looked into that very much.
I think it would be advantageous to somehow reunite the APIs, so that
applications can do both analog and digital TV easier and some code
duplication in the kernel can be avoided.

Marcus

-- 
/--------------------------------------------------------------------\
| Dr. Marcus O.C. Metzler        |                                   |
| mocm@metzlerbros.de            | http://www.metzlerbros.de/        |
\--------------------------------------------------------------------/
 |>>>             Quis custodiet ipsos custodies                 <<<|