Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[vdr] Re: dxr3/vdr problem



On Wednesday 05 March 2003 08:47, Marcus Metzler wrote:
> Malcolm Caldwell writes:
>  > (Kai - I home you don't mind - I think this discussion might receive
>  > better response on the dvb email list.)
>  >
>  > This thread started when I wrote that I was having problems trying to
>  > run vdr with a budget card using a dxr3 as the output.  I don't think I
>  > am the only one.
>  >
>  > The problem is I have a poor quality signal (due to various factors
>  > including weather).
>  >
>  > These errors get through the dvb driver to vdr and on to the the dxr3.
>  > The dxr3 device crashes - sometimes requiring a restart of vdr to reopen
>  > the device etc, sometimes requiring a reboot.  Others have reported
>  > having to reload the dxr3 drivers.  (although reloading the dxr3 drivers
>  > has never worked for me - but thats OT)  My system only ever runs a few
>  > hours before crashing.
>  >
>  > Kai argues that the dvb drivers should not be passing frames with errors
>  > through to applications.  Given that there is FEC etc in the dvb spec
>  > this may be so - I don't know.  I also don't know if a budget card is
>  > capable of doing this.
>
> All the error correction required and possible for the DVB
> signal is already done by the frontend. Any remaining errors cannot be
> fixed on the transport stream level.
> It would not make sense to check the MPEG stream on the ES level
> inside the driver. It is the task of the MPEG decoder to fix or ignore
> these problems. E.g. the hardware MPEG decoder of the av7110 already does
> these things which are often necessary for MPEG streams received from a
> error prone source. The dxr3 decoder is probably a little more picky
> because it was not developed for decoding a broken stream.
>

I think I was misunderstood. 
I don't doubt that the frontend fixes all fixable bit errors. I just mentioned 
that the uncorrectable errors should be flagged within the TS packet header 
(as it is defined in the standard). With the information about defect TS 
frames it would be easier to find (and correct / ignore or what ever) the 
defect PES frames. 
At the moment there are no information channels about defect packets in vdr 
(such channels are mentioned but not defined within standard).

And for me it makes no sense to check the PES / ES stream  for potential bit 
errors if this knowledge was present in the lower layers (for a error free 
stream this would be only a waste of cpu time).

- Kai -







-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe vdr" as subject.



Home | Main Index | Thread Index