Mailing List archive

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

[linux-dvb] Re: It works!



Johannes Stezenbach wrote:
Marcus Metzler wrote:

Johannes Stezenbach writes:
> > There are no 204 byte TS packets, the extra bytes are read solomon
> error correction data (which are useless for us). See EN 300 429.
> > What you did in your first "hack" was exactly the right thing to do:
> - invert the sync byte if necessary
> - discard the bytes after the 188th
> > IMHO there's no need to complicate the dvb-core layer because of this.
> > Johannes
>
There could be a problem if the presence of the error correction bytes
indicates that error correction has not been performed, so he may have
to add error correction before discarding the extra bytes.
All this should be done before feeding the data to the demux layer and
would not require a change of the core layer. In any case, it would be much better if the hardware can be persuaded
to do those things itself.
We would have to implement software-error correction for DVB over IP anyway, the received UDP packets are in 204-byte format too. But this is another project, see below...

While possible, IMHO it's unlikely that Twinhan chose not to use
the stv0299 internal error correction. I think they just wanted
to save a pin on their ASIC and didn't decode the stv0299's D/P signal.
The stv0299 RS register (address 0x33) allows you to pass-through the 16 extra bytes even when the error correction has been performed. Also the 0x47-sync-byte inversion can get enabled and disabled in this register independently.

So it's basically just another stream format for the demux, and since some hardware demuxes support input stream modes in all 3 formats (188, 204 and 130 bytes packet length) we could use this approach for the software demux as well.

Holger



--
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.



Home | Main Index | Thread Index