Kailash,
I did some benchmarks on my ARM platform (BeagleBoard X-15) today.
It's a bit more powerful than the E312 (A15 at 1.5 GHz versus A9 at 866
MHz).
DVB-T transmitter performance is pretty good, looks like a 3 MHz
waveform (3.43 Msps) is entirely possible.
DVB-T receiver performance is not so good. It can sustain about 300k sps
after OFDM symbol acquisition. One thing to know about is that the OFDM
symbol acquisition takes a lot more CPU when it's hunting for
synchronization. If you have an overflow due to poor performance or you
lose symbol synchronization for any other reason (usually frequency
offset), it can take a fairly long time to regain symbol
synchronization. So you lose large chunks of A/V bit-stream.
Note that the primary performance bottleneck is the Viterbi decoder. It
may be possible to add NEON SIMD instructions to boost the performance,
but that's a lot of work.
I'm afraid the E312 (or anything ARM based) is just not the correct
platform for the DVB-T receiver.
Ron
On 02/20/2018 02:57 AM, kailash kumar wrote:
Hi Ron,
Thanks for your input.
Here is the combination tried by me:
Mpeg Input Stream with Audio at 64K and video at 200K max(Total 264K
for 144p resolution)
Sample rate: 310K
Using calculation mentioned tried below combination with QPSK:
CR: 2/3, GI: 1/16, CP: 512 (Bit Rate: 264679.9)
CR: 3/4, GI: 1/32, CP: 256 (Bit Rate: 306788.1)
CR: 5/6, GI: 1/8, CP: 1024 (Bit Rate: 312469.4)
With this, there is heavy packet loss at receiver end (almost 50%) and
A/V mismatch issues persists.
I tried using multiplier block to mitigate packet loss to some extent.
Anything else that I might be missing? Any other way to get live
streaming working with GnuRadio?
Any way to achieve high RF throughput for higher quality video streaming?
Thanks
Kailash
On Tue, Feb 20, 2018 at 12:41 PM, Ron Economos <[email protected]
<mailto:[email protected]>> wrote:
Kailash,
The DVB-T receiver is very compute intensive. Even on a 4 core
X86 processor, it may be difficult to run the example flow graph
with the default parameters. To make matters worse, the SSE2
optimizations in the Viterbi decoder are not available on ARM.
For smooth playback, you have to match the Transport Stream
bit-rate to the sample rate. Here's a program to calculate the TS
rate from the sample rate.
http://www.w6rz.net/dvbtrate.c
For the 310k sample rate you're using, the bit-rates would be:
QPSK 1/4 1/8 1/16 1/32
coderate = 1/2 168733.5 187481.6 198509.9 204525.4
coderate = 2/3 224977.9 249975.5 264679.9 272700.5
coderate = 3/4 253100.2 281222.4 297764.9 306788.1
coderate = 5/6 281222.4 312469.4 330849.9 340875.7
coderate = 7/8 295283.5 328092.8 347392.4 357919.5
QAM-16
coderate = 1/2 337466.9 374963.2 397019.9 409050.8
coderate = 2/3 449955.9 499951.0 529359.9 545401.1
coderate = 3/4 506200.4 562444.9 595529.8 613576.2
coderate = 5/6 562444.9 624938.7 661699.8 681751.3
coderate = 7/8 590567.1 656185.7 694784.8 715838.9
QAM-64
coderate = 1/2 506200.4 562444.9 595529.8 613576.2
coderate = 2/3 674933.8 749926.5 794039.8 818101.6
coderate = 3/4 759300.6 843667.3 893294.8 920364.3
coderate = 5/6 843667.3 937408.1 992549.7 1022627.0
coderate = 7/8 885850.6 984278.5 1042177.2 1073758.4
The combined video and audio bit-rates have to be less than the TS
rate.
Also, when you change the guard interval, you have to change the
CP length on the OFDM Cyclic Prefixer. 1/32 = 256, 1/16 = 512, 1/8
= 1024 and 1/4 = 2048.
Ron
On 02/19/2018 10:00 PM, kailash kumar wrote:
Hi,
I am using DVT module for realtime streaming of mpeg ts file.
MPEG -> DVT -> USRP <----> USRP -> DVT -> UDP Sink -> VLC
I am having following issues wrt performance:
1. Audio is not not synced with respect to video frame causing
stutter or video getting stuck on VLC.
2. At times video gets stuck and unable to recover on VLC.
Here is what I have tried so far:
1. Stripping down video to 240x144 at 10 fps or less to cut down
on bandwidth requirements
2. Varying audio bit-rates from 32 to 384 Kbps.
3. Trying out different combination of sample rates and tx/rx
frequency.
4. Varying code rate and guard interval
5. Trying out different combination of modulation techniques
(QAM/QPSK).
I am attaching tx and rx grc files for reference.
Please let me know if something is missing from the flowgraph to
achieve decent real-time streaming from one E312 USRP to another.
Thanks
Kailash
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
