Hi Ron, Thanks. I tried with E312 using network mode. Tuning code-rate, guard interval, mux-rate (as per sampling rate calculation suggested by you), I was able to get almost real-time A/V streaming on an 8-core X86 host.
ARM architecture performance was not commendable (as confirmed by you as well). One last question; with an mpeg having only audio, X86 host based DVT had few issues. At times audio would get stuck and would take a while to recover. Video plus audio was much better however. Any particular area you can recommend that I should be looking at? Thanks Kailash On Thu, Feb 22, 2018 at 2:05 PM, Ron Economos <[email protected]> wrote: > 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]> 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 > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
