[linux-dvb] Re: V4 Denc API Proposal

[Johannes Stezenbach <js@linuxtv.org>]

Rob.McConnell@Zarlink.Com wrote:
> Johannes Stezenbach <js@linuxtv.org> wrote on 11/10/2004 11:46:40:
> > 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.

It is rather trivial to decode EN 300 472 packets, due to the
alignment guarantees within TS packets (if PUSI: header + 3 VBI lines,
else 4 VBI lines). The API allows us to simply copy the VBI data
to the DENC in the kernel without going through userspace. And note
that if you want you can still get the data in userspace and
write them back to the DENC manually.
Also, on av7110 PCI cards there is no way to write VBI data to the
DENC directly, the passthrough mode from demux to DENC is the
only thing we have. (Perhaps that's the main reason to have that
feature, otherwise it is not strictly necessary, just convenient.)

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

Well, in practise EN 301 775 data does not exist in broadcast streams ;-/
So forget it, no one would SET_VPS_SOURCE etc. for real.
(I'm sorry I brought up EN 301 775 at all.)

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

How does it matter to the API how the data is delivered to the DENC?
It seems like an implementation detail to me. If you mean that the DENC
has two different source and we need to switch, then I would say we
wait until actually has a usecase for this before we clutter up the
API with unnecessary stuff.

Regards,
Johannes