manu at kromtek.com
Wed Feb 16 12:06:48 CET 2005
> -----Original Message-----
> From: linux-dvb-bounces at linuxtv.org [mailto:linux-dvb-bounces at linuxtv.org]
> On Behalf Of Manu Abraham
> Sent: Wednesday, February 16, 2005 3:04 PM
> To: Hari_Mohan
> Cc: linux-dvb
> Subject: Re: [linux-dvb] [RFC]
> Hari_Mohan wrote:
>>From: linux-dvb-bounces at linuxtv.org [mailto:linux-dvb-bounces at linuxtv.org]
>>On Behalf Of Manu Abraham
>>Sent: Wednesday, February 16, 2005 2:11 PM
>>Subject: Re: [linux-dvb] [RFC]
>>>I don't know much about this but I have seen this in a dvb demodulator
>>>output and ASI convertors. These lines were termed DVALID and these used
>>>stay high whenever there is valid data in the transport stream
>>>bus-8bit/serial. This line stays low when there are some special
>>>coming in the bus. I think this flag is related to that. Even error line
>>>also is similar - ie whenever there were some uncorrectable errors this is
>>>supposed to stay low - depends on your configuration
>>What i was wondering was that, whether this information could help in
>>the upper space DVB API/driver in any manner, in terms of error
>>correction and or other aspects.
>>According to my knowledge mpeg decoder chips will clock in the data based
>>the state of these lines. I don't know whether any hardware mechanism is
> So is this information more reliable than the 13818-1 Discontinuity flag.. ?
> such that this information can be used to identify cases where we have
> problems in the TS.. ?
> since under the Linux DVB API, we don't have an exact solution for
> discontinuity, and TS errors to a 100% effectiveness, would these flags
> be useful for solving that problem ?
> For a particular DVB card, i can get these signals out from the frontend
> to the card and the driver.. So, considering that aspect if i get these
> flags out, i was wondering whether it would be possible to have a
> solution for the latter errors..
> That was the query that i had in my mind..
> The error bit which I am speaking about is the signal which is given by
> demodulator or a receiver device once it finds that input ts packet is
Yes, that's the one what i was referring to..
> errored. But the discontinuity indicator which you refered is inside the
> transport stream - so these information which are inside stream are inserted
> from the stream generator (encoder/mux) and I don't think that tuner will be
> reading this data to give the error signal/flag.
What i was thinking was that if the demodulator detects a broken stream
and or inconsistencies, this would also result in broken TS's and CRC
> For discontinuity in transport stream you can tweak software or add some
> patches but for errored input signal indication I don't think anything can
Some patches have already gone in regarding broken streams, but that
still doesn't seem to solve all the issues.
That only made me think in this aspect, as well as the availability of
these flags. These cards do not feature a MPEG decoder.
> be done other than making satellite/cable reception proper.
So do you mean to say that these falgs can be helpful only for MPEG
decoders and so on ?
When we are doing Software MPEG decoding, rather than Hardware doing it,
would it be possible to make use of these flags ?
>>there to store these values and use for upper layer applications. Because
>>stv299 may have separate APIs to calculate BER and signal quality.
>>>From: linux-dvb-bounces at linuxtv.org [mailto:linux-dvb-bounces at linuxtv.org]
>>>On Behalf Of Manu Abraham
>>>Sent: Wednesday, February 16, 2005 12:27 AM
>>>Subject: [linux-dvb] [RFC]
>>>Is there any advantage in getting the following flags out from the tuner
>>>(STV0299 based).. such that it might be of some help.. ?
>>>(1) data valid
More information about the linux-dvb