Mailing List archive

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

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



On Thu, Oct 31, 2002 at 02:21:31AM +0100, Felix Domke wrote:
> > I'd like to invite everybody to review the audio/video decoder and demux
> > API. We'll freeze everything soon and want to make a release again, so
> > please stand up and make your suggestions now if you think that things
> > should get changed/cleaned up.
> 
>  - payload type for normal demux. for example, allow (instead of only PES)
> raw TS without using DVR.

Sounds like a reasonable thing to have. But see below.

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

> just a question: is there a well-documented, strict specified way of the
> order while doing zapping? 

Unfortunately not.

> for example, WHEN to i have to issue which
> VIDEO_* command, when do i have to enable the pidfilters and so on.

What works well for us is:
- first establish a TS feed (i.e. tune the frontend and check for success)
- then set filters (PES/sections)
- then tell the MPEG decoder to start
- before tuning: first stop the MPEG decoder, then stop all filters

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.

---------------------
My 2¢ demux API rant:

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

This is more a long-term project since the current driver is fairly
stable and works well for many applicatons. But I would like to
see DMX_GET_CAPS defined properly, and if someone would do
some work on a libdvbdemux then someday we could remove the
multiplexer stuff from the driver.


Regards,
Johannes


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



Home | Main Index | Thread Index