Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linux-dvb] Re: V4 Denc API Proposal



On Monday 11 October 2004 14:58, Rob.McConnell@Zarlink.Com wrote:
> 
> 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 : )
> 
> 
Hi Rob,

the DBox2 is able to.
The Implementation is done within the C-Cube AviaChipset. 
Output is then forwarded to the Philips SAA718x chip for being modulated into 
the VBI.

regards

marcel




Home | Main Index | Thread Index