[linux-dvb] [RFC]

Hari_Mohan Hari_Mohan at Satyam.Com
Wed Feb 16 13:10:05 CET 2005

-----Original Message-----
From: Manu Abraham [mailto:manu at kromtek.com] 
Sent: Wednesday, February 16, 2005 4:37 PM
To: Hari_Mohan
Cc: linux-dvb
Subject: Re: [linux-dvb] [RFC]

Hari_Mohan wrote:
> -----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:
>>-----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 2:11 PM
>>To: Hari_Mohan
>>Cc: linux-dvb
>>Subject: Re: [linux-dvb] [RFC]
>>Hari_Mohan wrote:
>>>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
>>>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
> on
>>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
> from the stream generator (encoder/mux) and I don't think that tuner will
> 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.

I don't have much idea about v4l drivers but still if you can tell me the
issues I can try some suggestions. If you are trying to record videos then
you can avoid the bad vid pes packets. But if you are playing a video
realtime you may face problems.


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

Do you have APIs which give access to these flags. If you have it then the
possibility can be explored. Which is the video codec s/w used in this?

> Hari
> **************************
>>there to store these values and use for upper layer applications. Because
>>stv299 may have separate APIs to calculate BER and signal quality.
>>>-----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 12:27 AM
>>>To: linux-dvb
>>>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
>>>(2) error

This email (including any attachments) is intended for the sole use of the
intended recipient/s and may contain material that is CONFIDENTIAL AND
PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or
distribution or forwarding of any or all of the contents in this message is
STRICTLY PROHIBITED. If you are not the intended recipient, please contact
the sender by email and delete all copies; your cooperation in this regard
is appreciated.

More information about the linux-dvb mailing list