|
From: | Ron Economos |
Subject: | Re: On data formats in GR coding layer |
Date: | Tue, 12 May 2020 04:34:05 -0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 |
It's just a design choice made in the original code (1). It avoids unpacking and repacking code in every block. Also, the LDPC and BCH blocks were not really meant to used stand-alone, only as part of a complete DVB-S2 or DVB-T2 transmitter flow graph (which inputs standard MPEG-2 Transport Streams).
If you have already existing data in some other format, you can
use the built-in Byte Operators blocks (Packed to Unpacked, Pack K
Bits, Repack Bits, Unpacked to Packed and Unpack K Bits) to
convert back and forth.
Ron
(1) https://github.com/G4GUO/datvexpress_gui
Hi guys,
I have some feedback regarding data i/o formats in your coders, specifically DVB-S2 LDPC and BCH. Played around with it for a while when reading the theory of their construction and noticed that you are using bit-per-byte format instead of densely packed bits.
Why should a consumer and a user of your API be concerned about intrinsic esoteric data formats, i.e. if I give a binary bit stream, I expect Encoder block to give me encoded binary dump instead of first manually converting it to LSB's and then back to densely packed stream.
Unfortunately, to the best of my knowledge, it doesn't work this way currently.
Would be very grateful if you have some free time to answer.
KR,
Marko
[Prev in Thread] | Current Thread | [Next in Thread] |