[linux-dvb] Re: Fw: DVB audio/video decoder API

[Ralph Metzler <rjkm@metzlerbros.de>]

Johannes Stezenbach writes:
 > On Thu, Oct 31, 2002 at 02:21:31AM +0100, Felix Domke wrote:
 > >  - "receive buffer size". not the DMX_SET_BUFFER-thing (so not the
 > > ringbuffer size), but instead (on hardware layer) the interrupt frequency.
 > > for example:
 > > on hi-datarate services, specify a high number. the user will geht few but
 > > big packages of data. on lo-datarate services (maybe someone likes to stream
 > > the TOT in a TS, not using sections) specify 0 for "on every ts packet".
 > 
 > Can you elaborate on the effects this would have on existing drivers
 > and the hardware independent parts of the DVB driver source? Is this
 > just an optimization hint passed to the hardware drivers which can
 > be ignored (e.g. the current AV7110 firmware does not support this)?


The AV7110 firmware had some support for this. But this did not really
have much effect due to the DPRAM bottle-neck.
The newer firmware which delivers TS packets (for non A/V-PIDs) also
has no space (unless one throws out OSD) or time left to do any 
buffering. Additional buffering in the driver at the kernel demux
layer could be done if you really want to.

For other hardware we have used such a mechanism by directly adapting
the hardware buffer size of each hardware filter. The kernel API
supports setting the buffer size but has no rules about the delivery
(like your 0 for "on every ts packet").

 
 > The driver IMHO has internal "before/after tuning" hooks that should
 > take care of this, but...
 > Some frontends automatically mute the TS output when the signal is
 > invalid to avoid feeding crap to the demux/MPEG decoder, but an invalid
 > PES filter might still feed section data to the MPEG decoder, which
 > won't do no good.


Yes, as in TC and/or TPP (Traffic Controler, Transport Packet Parser) 
hardware going bye bye ...

 
 > As I explained in http://www.linuxtv.org/mailinglists/linux-dvb/2002/10-2002/msg00013.html,
 > the API was initially developed by Nokia, and we didn't dare to make
 > substantial changes to it for a long time.
 > 
 > One thing the driver does which I think it shouldn't is emulating
 > demux features in software that the hardware doesn't have.
 > E.g. the AV7110 does not give us the TS, thus the output for
 > the dvr device must be recreated in software from PES packets.
 > IOW, there's a complete TS multiplexer implementation in the
 > driver.
 > 
 > IMHO this should not be done in the kernel, but in a userspace library:
 > - DMX_GET_CAPS must be defined properly
 > - we need a libdvbdemux that looks at DMX_GET_CAPS and takes care of
 >   emulating features that the hardware does not have if the user
 >   requests them


That would give a major headache (as it did for us) in the case of the
AV7110 card because it even gives you different data formats for
the same kind of filter (or what should be the same kind) depending on
where the data comes from (A/V or not).
I planned to look into also getting the TS packets of the A/V data
which is currently displayed but currently I have no time to work on
the AV7110 card and the next full featured card we support will 
definitely not have such problems.



Ralph




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