Hamish Moffatt wrote:
The FIFOs there are usually tiny and only big enough to compensate the clock jitter. There is no guarantee that the TS header is still in the FIFO when an error occurs.On Mon, Feb 09, 2004 at 07:16:16PM +0100, Holger Waechtler wrote:Hamish Moffatt wrote:There are FIFOs to smooth the MPEG clock jitter, but it's pretty unlikely that anything there is related to the error indicator bit in the TS header.Is it possible that the transport errors are actually caused by buffer overflows inside the frontend? Is there a way to detect that? (Does it even have buffers?)
Hmm. No chance that if the FIFO overflows, the chip flags the corrupted packets with the transport error bit so that software will discard them? Hard to tell without detailed data on the frontend chips.
Hmmm, do you have a simple test program that can reproduce this? If not, can you create one? This should help understanding what's happening...In MythTV when I'm changing channels on the Avermedia card (sp887x, microtune frontend plus bt878 bridge), about 30-50% of the time I get non-stop errors. If I quit from live TV and go in again (which doesn't involve retuning the frontend), it works OK. No change in BER/UNC from femon.Hmm, don't understand what you mean here...
OK, I'll try to explain better. I'm watching station X, and everything
works fine, in live TV in MythTV. Then I tell Myth to change to station
Y, which involves changing frequency (and perhaps FEC rate & guard
interval) as well as new pids.
After changing I get continuous transport errors and the picture/audio
breaks up. It doesn't seem to resolve within a few seconds. If I quit
live TV, Myth keeps the frontend running and tuned. I don't know if it
disables the demux or not. When I go back to live TV, Myth doesn't have
to change frequency etc. However I no longer have the non-stop transport errors!
Maybe some part of the frontend is not reset correctly, you could add some printk()'s to check what is done differently in those cases...Alternatively, once the problem starts on a certain channel I can change to another where everything works. Often if I change back the problem will start again. I don't see how that can be caused by on-air corruption; I think it must be caused by a buffer overflow somewhere. What do you think?