-----Original Message----- From: Manu Abraham [mailto:manu@xxxxxxxxxxx] Sent: Wednesday, February 16, 2005 9:02 PM To: Hari_Mohan Cc: linux-dvb Subject: Re: [linux-dvb] [RFC] Hari_Mohan wrote: > > -----Original Message----- > From: Manu Abraham [mailto:manu@xxxxxxxxxxx] > 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@xxxxxxxxxxx [mailto:linux-dvb-bounces@xxxxxxxxxxx] >>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@xxxxxxxxxxx [mailto:linux-dvb-bounces@xxxxxxxxxxx] >>>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 >>> >>>to >>> >>> >>> >>>>stay high whenever there is valid data in the transport stream >>>>bus-8bit/serial. This line stays low when there are some special >>> >>>characters >>> >>> >>> >>>>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 >> >>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 > > 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 > failures. > > >>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 Broken TS's and CRC failures.. I see them once a while.. I still got to find out where that happens though. ???????????????????????????????????? In fact I remember that these signals and its use were explained in one of the dvb bluebooks document. I have seen this document in the year 2000. If you can get access to those documents may be it'll solve your problem. Hari ???????????????????????????????????? > you can avoid the bad vid pes packets. But if you are playing a video > realtime you may face problems. I am not trying to record a video here.. but rather playing it.. > > Hari > ~~~~~~~~~~~~~~~~~~~~~~~~~~ > > >>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? It could be any codec.. Currently for the MPEG2 TS i am using mplayer. > > Hari > @@@@@@@@@@@@@@@@@@@@@@ > >>Hari >>************************** >> >> >>>there to store these values and use for upper layer applications. Because >>>stv299 may have separate APIs to calculate BER and signal quality. >>> >>>Hari >>>--------------------------------- >>> >>> >>> >>> >>> >>> >>>>Hari >>>> >>>>-----Original Message----- >>>>From: linux-dvb-bounces@xxxxxxxxxxx > > [mailto:linux-dvb-bounces@xxxxxxxxxxx] > >>>>On Behalf Of Manu Abraham >>>>Sent: Wednesday, February 16, 2005 12:27 AM >>>>To: linux-dvb >>>>Subject: [linux-dvb] [RFC] >>>> >>>>Hi, >>>> >>>>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 >>>> >>>> >>> >>> > Manu ************************************************************************** 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. **************************************************************************
