[linux-dvb] Re: V4 API questions

[Michael Hunold <hunold@convergence.de>]

Hello,

On 04/01/04 12:02, Alasdair FARMER wrote:
> Within a TS there are PIDs for what is called 'Audio Descriptor' data. 
>This is an audio stream which contains a description of what is happening
>in a scene for the visually impaired.  This audio data may need to be
>processed and treated separately from the main audio data and may well
>need to be decoded/processed in a different way to standard audio data.
> 'Audio Descriptors' are being adopted by a number of broadcasters and
>support is being specified as mandatory for a number of new STB's

Ok, I understand. I suspect you need a second audio decoder on your STB 
to decode that stream in hardware and have it mixed together with the 
primary audio, right?

Hm, I'll need to look this stuff up before I can futher comment on this.

Do you have proposal how this could be handled?

> > I'd say that audio output is muted if playback speed != 1 (ie. live 
> > view), although that I admit that adjusting the playback 
> > speed around 1 
> > would give cool effects. 8-)
>
> While muting may be the route that some applications want to take,
> this is not a route appropriate for all applications.  Specifically
> some CE devices typically support audio playback for trick modes
> between 50% & 200%.  The problem I have is there is no way to
> provide synchronisation between audio and video - or am I missing
> something ?

Muting isn't mandatory, it's just that it will happen most likely on 
most devices. Perhaps we should introduce a capability flag that shows 
the range in which the decoder can handle audio playback.

If you set your video decoder to playback at 75% of the original speed, 
your device supports audio playback for that and the user hasn't muted 
audio, why shouldn't your device simply play back video and audio in sync?

> > > 4) What is the naming convention for decoders now that the linkage
> > > between decoders and demux's is dynamic ?
>
> > Hm, audio and video mpeg decoders are simply enumerated.
> It would be nice if it was possible to ask the demux what the 'attached' decoders were as there is no implicit mapping between demux's and decoders
In video.h we have:

enum dvb_video_source_type {
	DVB_VIDEO_SOURCE_DEMUX,
	DVB_VIDEO_SOURCE_MEMORY
};
struct dvb_video_source {
	enum dvb_video_source_format format;
	enum dvb_video_source_type   type;
	int                          demux_fd;
};

So you can specify which demux (via the file descriptor) should be 
connected to your decoder.

Isn't that sufficient?

> Well the answer is I guess most of ST Microelectronics STB (& DVD) current and next generation of silicon.  (ST's solutions are present in 80% of STB's worldwide).  We are looking to better support LinuxDVB - but we have to be happy that the API will actually do the job for us.  In general it looks like it probably will (assuming it continues to mature as it has been), I am just digging deeper to check.  The V4 API is the first iteration which is beginning to look like a 'real' API that we could use.
That sounds good. Then we should make sure that it fits your needs, too. 8-)

> Regards
> Ali Farmer.
CU
Michael.


--
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.