On 12/27/2011 12:12 PM, Christian Prähauser wrote:
Yes, I'm meaning something like what it was described there. I think
that the code written by Christian were never submitted upstream.
Hello Mauro,
Konstantin drew my attention to this discussion. Indeed, some time ago I wrote
a base-band demux for LinuxDVB. It was part of a project to integrate support
for second-generation IP/DVB encapsulations (GSE). The BB-demux allows to
register filters for different ISIs and data types (raw, generic stream,
transport stream).
I realized that the repo hosted at our University is down. If there is interest,
I can update my patches to the latest LinuxDVB version and we can put them on a
public repo e.g. at linuxdvb.org.
Kind regards,
Christian.
I have a question which is a little bit off-topic for that thread but I
would like to ask since I think you could have some idea.
FEC Code Rate is often given as k/n, for example FEC 1/4. But nowadays
there is also seen 0.x like FEC 0.8.
I have feeling that this is due to new inner coding used, LDPC instead
of traditional convolutional codes. When convolution codes were used it
was correct to define 1/2 as basic rate and puncture rest from that. But
as now with LDPC we have larger blocks we cannot represent so easily.
For example DTMB uses LDPC(7488,6016) = 6016/7488 = ~0.8034 => FEC 0.8
is used.
I am adding DTMB support for DVB API and that's why I have to think if I
extend old k/n FECs or define new ones as FEC 0.4/0.6/0.8.
regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
