[linux-dvb] Re: V4 Denc API Proposal

[Rob.McConnell@Zarlink.Com]

Hi Johannes,

Thanks for the comments.  See below for more input. ; )

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

> On Mon, Oct 11, 2004 at 07:59:00PM +0100, Rob.McConnell@Zarlink.Com
wrote:
> > Please find attached a revised version of the V4 DENC API that now
includes
> > the ability to set the teletext source to be from a demux or rec-656
device
> > or memory.  I have also added the ability for the closed-caption source
to
> > be set to a rec-656 device or memory.  REC-656 can contain ancillary
data
> > in the blanking period.  The ancillary data can be teletext, closed
> > caption, or many other data types (e.g. audio).
>
> What is the use case for this? Just that some DENCs on the market
> have this capability doesn't mean it makes sense to have it
> in the API.

Surely if a DENC can decode this ancillary data and insert into the VBI,
then it is a valid source that should be in the API.  This may be the only
means of getting teletext data inserted into the VBI for some DENC devices.
We shouldn't single them out and say "sorry" should we?

It may be worth having a think about creating a REC-656 API for
encoder/decoder devices.  REC-656 is handled by many STB chips nowadays and
having an API may be beneficial.

>
>
>   /*! Used to set the input source */
>   struct dvb_denc_source {
>      enum dvb_denc_source_type   type;  /*!< input source type */
>      int                         fd;    /*!< file descriptor of the
> device (video/video scaler, OSD or REC-656) */
>   };
>
> We would have difficulties in the implementation to use a non-DVB
> file descriptor here (OSD), and we have not yet decided on the
> scaler device. I would simply enumerate the inputs 0..N. It is
> totally hw dependent what they mean (e.g. 0 == mixture of various
> scalers and OSD layers, 1 == only one scaler (for VCR)).

OK, so keep the fd for handling of data from demux and or other devices and
simple change dvb_denc_source_type to be an "int".  At least this way, we
can have enum (e.g. DVB_DENC_SOURCE_xxx) for the future and not affect the
sizeof the structure.

>
>   enum dvb_denc_ttx_source_type {
>      DVB_DENC_TTX_SOURCE_DEMUX,  /*!< pass through the demux decoder feed
*/
>      DVB_DENC_TTX_SOURCE_REC656, /*!< REC-656 ancillary data (VANC) */
>      DVB_DENC_TTX_SOURCE_MEMORY, /*!< directly into the decoder via
> the DVB_DENC_SET_TTX ioctl */
>   };
>
> We don't need DVB_DENC_TTX_SOURCE_MEMORY, we have DVB_DENC_SET_TTX.
> (If we connect to the demux DVB_DENC_SET_TTX must fail.)

You could argue that we don't need the DVB_VIDEO_SOURCE_MEMORY or
DVB_AUDIO_SOURCE_MEMORY as the write syscall implies this anyway.  I don't
see the difference between there being an ioctl or a write syscall.  Either
we drop them in the other devices or we stick to convention and allow
DVB_DENC_TTX_SOURCE_MEMORY for symmetry.

Agreed that DVB_DENC_SET_TTX should fail if we have a demux or other device
input.

>
> And I would like to drop that rec565 stuff. Keep it simple and stupid.
>

I can take a step backwards and drop the REC-656 handles, but many STB folk
will probably end up putting it back in for their purposes.  If it's there,
then I don't see any harm in keeping it.  OTOH, I can change any references
to REC-656 to be OTHER so that the API is more generic.  What do you think?

Another point worth mentioning is the different Teletext standards
worldwide as well as closed-captioning (e.g. with XDS). When we set the
teletext or closed-caption source, it might be beneficial to specify the
standard in the DVB_DENC_SET_TTX_SOURCE and DVB_DENC_SET_CC_SOURCE ioctls.
Any comments?

Thanks Again,

Rob : )