Video Streaming

GNU Radio
1

Hi

I am trying to stream a video over a wireless network using UDP
protocol.
For that, I started tests in the following sequence:

Test 1: VLC ---- VLC

Test 2: VLC ---- Gnuradio (using udp source and udp sink blocks
only) ---- VLC

Test 3: VLC ---- Gnuradio (with a complete communication model (e.g.
mod/demod)) ---- VLC

Test 4: VLC ---- Gnuradio ---- USRPs (multiple) ---- VLC

Test 1 completed successfully and the streamed video quality is perfect
at
the receiver end. Whereas, in test 2, test 3 and test 4 I’ve
successfully got the streamed video at the receiver end but the quality
is
not good (it’s even more degraded when shift to the
higher test levels). During the testing a warning message
appeared on gnuradio console i.e. Too much data; packet loss.

I tried to resolve this issue by adjusting the factors like payload
size and sampling rate but nothing works. The flowcharts and the video
are attached here for reference.

Furthermore, can anyone give me a hint that how can I check
the parameters like throughput, packet delay and SNR.

Kindly assist me and point out the mistake I’ve made, waiting for
earliest
reply. Thanks.

Regards,
Syed Aqeel R.

2

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Syed,

test 2 should be completely transparent and thus you shouldn’t lose
quality. The input bitrate of the video is below 1Mb/s, so for a pure
loopback test I can’t imagine this going wrong. Are you sure that the
sending VLC does not decode the video into something with a much
higher bitrate. Also make sure you don’t use throttle in between.

Greetings,
Marcus

On 20.02.2014 11:32, Syed Aqeel R. wrote:

Test 2: VLC ---- Gnuradio (using udp source and udp sink blocks
Test 1 completed successfully and the streamed video quality is

_______________________________________________ Discuss-gnuradio
mailing list [email protected]
Discuss-gnuradio Info Page

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTBxjSAAoJEAFxB7BbsDrLzxcH/ip3m6F2ls0itx95IlN2qov0
f3etC7XX0XgF91uO9XwpLSdjsIjGaXz8G7Yc7zKCkrcBL9xVuYl/xpqHKwxy2gWL
/FoROdlioZ7Nr/xWkuMTsRAJQgx/VIVWLSoSutdT4Bc7fc4z6lcosPDQ/ShUziw9
IZnfPfX2Wumh1QkOKkcIYxTjyIL1tqi6X2T3LrfHC3FBc2g3JL90xPFlc4hXfMHM
0zwkXNiSAVZxzRgbW5mHolygU80AvrP529B2mHD9hoiJfDTGLDvyxmsrU2E2Pc2Y
GCnIJ5bHQBENcemYeGceKtRsd9MO7TV9RyTOR4q2ghhIn1z2W+WFMvY4JwRG800=
=gDsk
-----END PGP SIGNATURE-----

3

On 02/20/2014 11:32 AM, Syed Aqeel R. wrote:

Kindly assist me and point out the mistake I’ve made, waiting for
earliest reply. Thanks.

Syed,

this not a reasonable thing to ask for here. You have built an entire
transceiver chain, and all you tell is that “it’s not working”.

Unless someone is extremely bored, no-one will help you with a request
like this.

No, I assume you actually want help, and are not posting this question
to annoy anyone. Here’s some advice:

Without even looking at your flow graph, I assume there’s several things
that aren’t working, since so much can go wrong in digital comms.

M

4

On 02/21/2014 04:44 PM, Martin B. wrote:

No, I assume you actually want help, and are not posting this question
to annoy anyone. Here’s some advice:

Without even looking at your flow graph, I assume there’s several things
that aren’t working, since so much can go wrong in digital comms.

To clarify my response, you should track down bugs one at a time. When
you have identified a specific subsystem that is not working as planned,
ask again. Have you also read the manual (regarding SNR estimation
etc.)?
Are you sure your transceiver does what it should? You could try other
transceivers, like the OFDM ones.

Also, please don’t post big files like the video on this list.

M