[linux-dvb] Re: It works!

["Augusto Cardoso" <augusto@carhil.net>]

HI!

To make things more complicated, the US-ATSC systems uses RS(207,187) and the DSS RS(146, 130). The actual implementation of the ATSC includes the sync byte. An ATSC TS interface uses either 188 or 208 bytes.
IMHO, supporting all these different transport sizes represent an unnecessary overhead. The Twinhan architecture makes no sense. It's very difficult to make a case to use software error correction, specially when it's already in the chip.
The only situation in which  I used the whole 208 bytes in ATSC, was during some trials and were trying to qualify some of the packet lost for the whole system. In this situation we had to receive raw packets for processing later and did all sorts of analysis.
What about a raw mode that allows you to receive the buffers, find your data and callback to process the packets? In other words, normal support for 188. For different variations, you have a "raw" mode for user side processing and feed the packets back or use the demux as part of a library in user space. I think this is almost available today.
Of course, there are lots of different ways to implement this.

	Augusto



*********** REPLY SEPARATOR  ***********

On 10/7/2003 at 2:52 PM Holger Waechtler wrote:

>Robert Schlabbach wrote:
>> From: "Johannes Stezenbach" <js@convergence.de>
>>
>>>Robert Schlabbach wrote:
>>>
>>>>From: "Holger Waechtler" <holger@convergence.de>
>>>>
>>>>>packet_length can be 130 or 188bytes, valid values for packet_stride
>>>>>could be 130, 188 and 204 bytes. If all constants '188' get replaced
>>>>>by these variables this should be flexible enough for all cases.
>>>>
>>>>Umm, what about 147 bytes? If I get this right, DSS uses 147 bytes
>>>>packets, of which 130 bytes are data, correct? So shouldn't a stride
>>>>of 147 bytes be supported as well...?
>>>
>>>Who cares about DSS?
>>>
>>>Rule #23: Don't implement stuff that maybe someone might need sometime.
>>>Wait until at least one user shows up who actually needs it.
>>
>>
>> And why do you support 130 bytes packet length then? It would make sense
>to
>> support neither or both 130 and 147 bytes, but IMHO it doesn't make sense
>> to have "half" DSS support in there.
>
>ooops, you are right! But aren't this 146bytes (130 data + 16 error
>code)? The sync byte seems to get usually removed in the demodulator.
>
>btw, the site Marcus mentioned tells us that the data length inside a
>DSS packet is 127bytes, so we now have 4 numbers to choose...
>
>Holger
>
>
>
>--
>Info:
>To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.





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