[linux-dvb] Re: cinergyT2: which kernel/usb module to use?

[Johannes Stezenbach <js@linuxtv.org>]

Holger Waechtler wrote:
> John Dalgliesh wrote:
> >On Mon, 29 Nov 2004, Klaus Schmidinger wrote:
> >>From an application programmer's view it really would be great if the 
> >>driver
> >>gurus could agree on a reference implementation of how exactly tuning
> >>and waiting for a lock is supposed to be done...
> >
> >I must be missing something here, but where is it useful to wait for lock
> >anyway - what's wrong with just waiting for some data to come through? I'm
> >not having much luck imagining an application where the demod's internal
> >idea of lock is any use waiting for, over just waiting for the actual
> >data that you want to get out to arrive.
> 
> It is not useful for anything, it just delays zapping. Ancient pre-v2 
> av711x-drivers required this for some card versions because the driver 
> did not shut down the PID filters when changing the demod parameter set 
> and some early stv0299 chip revisions (or was it the 1893? don't 
> remember for sure - ) did not muted the TS appropriately when running 
> out of sync but crashed the MPEG decoder by feeding the av711x with 
> garbled TS packets.
> 
> This was a hardware bug that was fixed in later chip revisions, and all 
> recent DVB drivers have some ugly workaround code for these broken PCI 
> cards (see the frontend notifier callbacks in dvb_frontend.c), so there 
> is no need to do tuning and filter setup in a particular order anymore. 
> You can simply set up all parameters and PID filters, start the MPEG 
> decoder and then watch the signal status statistics in regular intervals 
> if you want to display them in your OSD while rendering the video 
> picture on the background plane.

That's only half the story.

If you set filters before the input stream is stable, then you
must be prepared that the filters will output some garbage.
It is a specific problem of the av7110 firmware that it might crash
in such cases (which the workarounds in the driver try to prevent),
but the garbage problem exists alyways.

Another problem specific with video decoding is that some
decoders crash (including software one like ffmpeg) if
they are fed with a sequence header from one stream (which
contains the frame size), and then are fed with data from larger
frames from another stream without cleaning the buffers
inbetween. Due to the garbage problem you can only avoid
the issue by setting filters only after the input is stable.

BTW, in my experience the additional delay from waiting for a stable
input stream before setting the is a few msecs, unrecognizable to me.

Johannes