Mailing List archive

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

[linux-dvb] Re: V4 Denc API Proposal








linux-dvb-bounce@linuxtv.org wrote on 11/10/2004 13:16:22:

> 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 Marcel,

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

So this chip is able to parse the MPEG-2 PES packets, extract the teletext
data and then transfer it to the teletext bitstream input (that's cool).
That would imply that we probably only need a means (API) to connect a
denc/vbi device to the demux decoder feed for teletext data, not other data
types.

So to recap, we need a means to set the source of the teletext data to be
from the demux decoder feed _and_ to be able to write the teletext data
from user-space for h/w that doesn't have this capability.  I guess we
could have another ioctl:

DVB_DENC_SET_TTX_SOURCE  that selects between the DVB_DENC_SOURCE_DEMUX and
DVB_DENC_SOURCE_MEMORY.  Any comments?

Thanks for your input!

Cheers,

Rob ; )





Home | Main Index | Thread Index