[linux-dvb] Re: V4 API questions

[Michael Hunold <hunold@convergence.de>]

Hello Ali,

On 03/30/04 17:23, Alasdair FARMER wrote:
> 1) The dvb_dmx_decoder_type does not support Audio
> descriptor as a type.  A good number of broadcasters
> are starting to transmit this and it may have different
> decode requirements from a normal audio channel

I don't understand what an "audio descriptor as a type" means. 8-(
Can you specify your problem?

> 2) The playback speed seems to be modified from the video
> decoder - how is this supposed to modify the audio ?
> In many systems the audio is still 'rendered' (within
> certain parameters, say up to x2) as the playback speed is adjusted.

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

> 3) I am assuming that the recording stream mechanism works such
>that once you have set the PIDs to buffer, you just read from the demux ?

I'm currently working on writing some code around the recording filter 
stuff.

You can query the different recording types the device supports via  the 
DVB_DMX_GET_CAPS ioctl using the DVB_DMX_CAP_RECORDING_TYPES identifier.

If you just need the raw TS stream, then you can simply read() the data 
from the demux device if it's supported by the driver.

Some hardware support "event logging", ie. they provide additional data 
for the TS packets that have been processed (for example if PUSI or TEI 
was set).

Some hardware support h/w recording facilities with additional buffers.

If that is the case (use the query ioctl and check for 
DVB_DMX_REC_TYPE_BUFFERED and DVB_DMX_REC_TYPE_EVENT_LOGGING), the idea 
is to be mmap() the TS buffer directly and have the driver notify the 
application via poll().

You can then call the DVB_DMX_RETRIEVE_RECORDING_DATA to retrieve some 
offsets into the mmap()ed buffer which show you the valid data area.

Have a look at "apps/test/test_recf" for a sample application. The 
interface is currently only available for av7110 based cards, where the 
recording facilities are simulated in software.

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

> 5) What are (video) decoders expected to render to ?
Possibly some video layer, but this is out of scope of the DVB api. Your 
application needs to make sure that this layer has the right dimension, 
is visible etc., most likely through some other interface like DirectFB.

> 6) I am curious about how the API is intended to support features such
> as PIP & Dual output hardware (supporting multiple TV's / Ouputs).

PIP is supported by the ability to connect multiple frontends, demuxes 
and decoders. Multiple outputs are supported by assuming that you have 
multiple video layers which are handled like explained in 5).

> That’s it for starters... I await feedback with interest :-)
It sounds as if your have already some special hardware in mind. Does 
the V4 api suit that?

> Ali.
CU
Michael.


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