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

[Måns Rullgård <mru@mru.ath.cx>]

Gerd Knorr <kraxel@bytesex.org> writes:

> Rob.McConnell@Zarlink.Com writes:
>
>> 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.
>> However, there are requirements for video encoders (DENC) that don't appear
>> in the API.
>
> Jep, mainly because there is no driver yet (at least none known to
> me).  Just pulling some API spec out of thin air without at least one
> reference implementation usually doesn't work out that well.  Even one
> implementation doesn't ensures that you get a reasonable API.
>
> Right now I'm trying to work out a v4l2 ioctl to set MPEG encoder
> parameters (see latest v4l snapshots and the videodev2.h file
> therein).  Intention is to have some common API for all these cards
> which do mpeg hardware compression of the incoming, analog tv aignal:
> ivtv, saa7134-based (empress design), cx88-based (blackbird design).
> Comments on that are welcome.

I'm interested of development here, so please keep the list posted.

>> 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?
>
> I don't see that much overlap between the two, so I don't think it
> makes that much sense trying to merge them.  DVB handles digital
> input, v4l2 handles analog input.  You want to do something different:
> video output.

I posted some thought about these things on one of these lists some
time ago.  The way I see it, there are cards that have inputs and/or
outputs.  An input can be analog or digital, possibly connected to a
tuner, which in turn can be terrestrial or satellite, thus requiring
slightly different tuning parameters.  The chipset delivers the
content of the selected input to the host, possibly transforming it.
Possible transformations include encoding analog as MPEG (or some
other compression), decoding MPEG to raw pixels, scaling, cropping,
etc.  Finally, outputs can be analog (svideo, composite, whatever) or
digital.  Outputs may also have a modulator, as present in some STBs.
Data from the host is sent to a selected output, after applying
transformations, if supported.  Routing an input directly to an output
may also be possible.

Within this model, the average analog tuner card would have a few
inputs (s-video, composite, analog terrestrial tuner).  Some support simple
transformations like scaling and cropping.  Most have a single output,
the video overlay.

Cards like the MPEX in addition support the transformation of encoding
MPEG.

A regular DVB-S budget card has a single input, a digital satellite
tuner and whatever is associated with it.  Typically the only
supported transformations are PID filtering and descrambling.  These
cards have no outputs.

The API would consist of ioctls to query the capabilities of the card,
and select inputs, transformations, etc.

An MPEG encoder would support setting various stream parameters,
whereas a DVB card would only allow querying parameters,
i.e. identifying the data as MPEG TS.  Analog capture and MPEG
decoders would also use common means of describing the data format,
differing only in the read/writability of various parameters.

Is there something fundamental that makes such a common API
impossible?  I'll admit to barely having scratched the surface of
these drivers.

-- 
Måns Rullgård
mru@mru.ath.cx