[linux-dvb] Re: V4 Denc API Proposal

[Rob.McConnell@Zarlink.Com]

Hi Johannes,

Johannes Stezenbach <js@linuxtv.org> wrote on 11/10/2004 11:46:40:

> On Sat, Oct 09, 2004 at 12:08:16PM +0100, Rob.McConnell@Zarlink.Com
wrote:
> > Please find attached a header file "denc.h" that helps to illustrate
what
> > capabilities a digital encoder (denc) has.  A denc is normally found on
> > STB/iDTV products to convert a digital video signal into an analogue
form
> > (e.g. RGB, CVBS) to output to a TV/VCR/etc.  It also has the capability
to
> > insert data into the VBI (e.g. Teletext, WSS, VPS, closed caption).
> >
> > I have included the vbi functions from "vbi.h" in the header file so
that
> > STB/iDTV folk can simply have one type of device that does everything
> > (instead of having a separate denc and vbi device).  For PC Card folk,
just
> > use the vbi.h file as it is (probably needs extending to add Teletext
and
> > cc support).
>
> I think it is not useful to keep both vbi.h and denc.h.

I'm fine with that.

>
> What you left out of denc.h is the one thing which is needed
> most in practice (to implement EN 300 472 and EN 301 775):
> Handing VBI data from the demux directly to the DENC.

Yes, I was thinking about this over the weekend.  The current vbi.h and V4
documentation suggests setting up a demux decoder feed where the _hardware_
will transfer the EN 300 472/EN 301 775 private data *directly* to the
denc/vbi device.  However, I have not come across any hardware that
actually does this, have you?  This would imply that the hardware decodes
the PES packets to extract the relevant data (strip off any header info)
and then re-encodes it into the VBI.

What I have implemented so far allows an application to setup a demux PID
filter on the appropriate PID that contains the teletext/vbi data.  The
application can read this pid to obtain the relevant data and can then send
it to the denc/vbi device using the ioctls (DVB_DENC_SET_TTX,
DVB_DENC_SET_CC, DVB_DENC_SET_VPS, DVB_DENC_SET_WSS, DVB_DENC_SET_CGMS).
You could have a separate thread/process for each type of data.

If we do need to create a demux decoder feed->denc/vbi device, then I guess
it should support all types of data (ttx, wss, cc, vps) as suggested in EN
300 775.  The problem here is that you could have multiple decoder feeds
for the denc/vbi device.  Would it be sufficient to simply have
DVB_DENC_SET_TTX_SOURCE, DVB_DENC_SET_WSS_SOURCE, etc. ioctl's?

Another point worth mentioning is a lot of denc devices I've seen actually
have a dedicated teletext serial input port on them.  Here, the teletext
data is input to the dencs as a bitstream.  What I don't know is what
devices actually output a compliant bitstream to feed these denc devices,
do you?  We should at least have means of enabling/disabling teletext
insertion in this case.  What do you think?

> > A few companies have made comments on the lack of a denc API, so that's
why
>
> Who? To Whom?

I've had a private mail off someone who works for a company (I don't know
which one) porting the Linux DVB APIs to their hardware.  He has also run
into the same problems with lack of denc and video scaling/presentation
capabilities.  I've encouraged him to view his opinions on the ML so at
least we can get more overall feedback.

Cheers,

Rob : )