Re: [Discuss-gnuradio] Help with video link
Hello Alexandru thank you for your reply. At the moment I am using a loopback cable on the USRP. I have been using MPEG_TS as well but i noticed after reading your comment I was missing the mpegtsdemux on my receiver chain. I have something extremely crude operating now, though it is mostly a grey screen, the image isn't there yet. This is what I have set up so far: transmit chain: gst-launch v4l2src device=/dev/video0 ! 'video/x-raw-yuv,width=160,height=120' ! x264enc bitrate=1024 quantizer=10 tune=zerolatency ! mpegtsmux ! filesink location=txPIPE.ts receiver: gst-launch filesrc location=rxPIPE.ts ! mpegtsdemux ! queue ! h264parse ! ffdec_h264 ! xvimagesink sync=false and my GRC flow graph in between is: TX: File Source: repeat: no OFDM Mod FFT len: 512 Occ tones: 200 prefix: 20 pad for USRP: yes Payload length: 0 USRP Sink: samp rate: 500K RX: USRP Source: samp rate: 500K OFDM deMod FFT len: 512 Occ tones: 200 prefix: 20 pad for USRP: yes Payload length: 0 SNR: 20 File Sink: Unbuffered: off Append: Overwrite I have had trouble with a few things. What i notice when using an FFT Plot is that the signal is pulsating. I have been playing with CW values and gains on the USRP to see if that helps. It does somewhat but not totally. I wonder if this is a buffering issue. Though I have no feed back from my terminal, no underflow or overflow or TIMEOUT, both grstreamers are reporting to be playing (the rare time I get it through PREROLL into PLAYING on rx side) I have been trying all sorts of FFT sizes, occupied tones, grstreamer bitrate values to no avail. All I have been able to do there is just make it worse. I have the communication channel equations set up in excel so can input trial values and determine what my data rate through my flow graph should be, and then line that number up with gstreamer's bitrate. No luck there.. I had also considered using an error coding block (the CCSDS) but I read in the notes that comes with it the it wont work with packtised data. Which I am assuming then doesn't work with the MPEG-TS? I have bypassed the USRP with a throttle block and the signal is better. It's more of the really low quality 'man in the space station' style. As it is not that good, I figure some of my flow graph numbers are off or I've missed something in my gstreamer command string. Or my OFDM block is not set up right. I'm not sure what payload length should besides default value or what pad for USRP does. Alex On Wed, Mar 26, 2014 at 7:36 PM, Alexandru Csete oz9...@gmail.com wrote: Hi Alexander, The de-facto standard way for sending video over the air (assuming you can't use wifi-like links) is to encapsulate all video and audio into a single, constant bitrate MPEG transport stream (aka. MPEG-TS). It's a packetized format designed specifically for transmission over lossy channels. MPEG-TS is used for DVB-T, DVB-S and probably also ATSC. If you just want something quick dirty you can try: http://www.irrational.net/2014/03/02/digital-atv/ Alex On Wed, Mar 26, 2014 at 5:42 PM, Alexander Buckley albuck...@gmail.com wrote: Hello all, I am completely stumped with trying to stream video using gnu radio (GRC) and the USRP. I have been at it for an absurdly long time without success. I could really use some help. (With Unbuntu and the latest UHD/GNU radio) There has got to be someone who has done this, but so far google is not my friend. I have read so many sites of people looking for help and being given 'help' that doesn't work, the internet is now fully spammed when it comes to this subject. After days and days I read things like: 'To correctly and completely use the RTP payloaders on the sender and the receiver you need to write an application. It is not possible to write a full blown RTP server with a single gst-launch-1.0 line.' or that player 'x' isn't really player 'x' its a fork due to developers fighting and is rather broken.. Most of what I read is about streaming over a network with a constant frame rate (adaptive bit rate) which really does not relate well to USRP? I have tried countless permutations of command line strings with various options using gstreamer, ffmpeg, vlc. mplayer I have tried UDP and File sink/source. I once I had it nearly working but could not get the player to stream with a constant bitrate (which i think usrp would require?). I have lost track of which player that was though. At this point I am completely desperate for a a solution. I am looking for any solution that works (even badly). All I am to do is put together a demo, and it is becoming clear I have no idea what I am doing. Either that or this as far far less trivial than one would think. I would greatly appreciate some help here as this endeavour is now becoming quite expensive. regards Alexander Buckley ___ Discuss
[Discuss-gnuradio] Help with video link
Hello all, I am completely stumped with trying to stream video using gnu radio (GRC) and the USRP. I have been at it for an absurdly long time without success. I could really use some help. (With Unbuntu and the latest UHD/GNU radio) There has got to be someone who has done this, but so far google is not my friend. I have read so many sites of people looking for help and being given 'help' that doesn't work, the internet is now fully spammed when it comes to this subject. After days and days I read things like: 'To correctly and completely use the RTP payloaders on the sender and the receiver you need to write an application. It is not possible to write a full blown RTP server with a single gst-launch-1.0 line.' or that player 'x' isn't really player 'x' its a fork due to developers fighting and is rather broken.. Most of what I read is about streaming over a network with a constant frame rate (adaptive bit rate) which really does not relate well to USRP? I have tried countless permutations of command line strings with various options using gstreamer, ffmpeg, vlc. mplayer I have tried UDP and File sink/source. I once I had it nearly working but could not get the player to stream with a constant bitrate (which i think usrp would require?). I have lost track of which player that was though. At this point I am completely desperate for a a solution. I am looking for any solution that works (even badly). All I am to do is put together a demo, and it is becoming clear I have no idea what I am doing. Either that or this as far far less trivial than one would think. I would greatly appreciate some help here as this endeavour is now becoming quite expensive. regards Alexander Buckley ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] State of the art research
Hello all I have been trying to discover what is currently available in terms of open source, working out-of-the box, modules implemented in GNU Radio and the USRP, to use as a teaching aid with students. I am interested in a few things, waveform generation, protocol stacks and signal analysis. My questions: 1. Are there working examples for producing 3G, UMTS, LTE, WiMAX signals etc.? Are there implementations including MAC layer support? 2. Are there any implementations of a 'test vector analyser'? 3. What is available in terms of complete protocol stacks? I understand there is openBTS, though I read somewhere it is not yet compatible with the current version of GNU Radio. Is this true? What about openLTE? 4. Is there a repository for such projects that are updated that I have not come across yet? I have yet to find any real solid leads in my research for solutions. There are vague references to such projects, or papers and examples circa 2009-11 that I think are now depreciated in terms of GNUradio 3.7 compatibility. Any info/pointers would be greatly appreciated. Regards, Alexander Buckley ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Piped Video Streaming Crash
Hi Marcus
Hopefully your seeing this, for some reason that other
threadhttp://lists.gnu.org/archive/html/discuss-gnuradio/2014-02/msg00351.htmlis
no long in my mail inbox or trash..
My problem was:
VLC - Named Pipe 1 - File Source GRC - OFDM MOD - USRP Sink- USRP -Source -
OFDM DEMOD - File Sink GRC - Named Pipe 2 - Mplayer
(FAILS!!). Reports: Segfault (core dumped). GRC file is running, VLC is
streaming. Fail occurs as soon as I open Named Pipe 2 with Mplayer
using:
cvlc v4l2:///dev/video0 :v4l2-width=160 :v4l2-height=120
:v4l2-aspect-ratio=4/3 --noaudio
--sout=#transcode{vcodec=h264,vb=1024}:file{dst=./txPIPE.ts} :sout-keep
and reading with mplayer, where the error only occurs when I introduce the
USRP N210 to the circuit.
You had asked what was crashing, the play or the grc produced python set up.
It is the python/GNU radio that is crashing.
I have also had it report the following:
*** glibc detected *** python: realloc(): invalid pointer: 0x0a9c9450 ***
or
*** glibc detected *** python: malloc(): smallbin double linked list
corrupted: 0x0a9efcb8 ***
I have trouble seeing how this should be failing like this as I have used
the same set up to send a text file, with the only difference being that
the file read is set to repeat.
I have been thinking there could be trouble with data rates, though I had
expected that would all be taken care of by back pressure if nothing is
really specified.
I really am following the set up Alexandru Csete's. The only differences
being is that he is using a mac book, older usrp1 and gstreamer.
But i don't any of that should be the difference, the commands are quite
straight forward.
I had to try quite a few combinations of streamers/players to get it
to work initially without GRC stuff in the loop. The errors presented along
the way getting to that point were very different. But now that I have that
part sorted, the players don't complain or crash with what I am trying to
do.
It is the GRC-python file when the USRP is added. I am using my USRP for
all sorts of other things just fine though.
So again I keep coming back to data rates, buffers etc.
I do have this always displayed when i run my USRP, I have just always been
ignoring it:
UHD Warning:
The send buffer could not be resized sufficiently.
Target sock buff size: 1048576 bytes.
Actual sock buff size: 131071 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.wmem_max=1048576
Running sudo sysctl -w net.core.wmem_max=1048576 doesn't stop this warning.
But if I do have USRP buffer size problem, that does relate to segfaults,
malloc etc...
This is rather beyond my USRP knowledge level though
cheers
Alexander Buckley
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Piped Video Streaming Crash
Hello all
Sorry if this is a duplicate, haven't found a thread with me specific
config (no UDP).
System:
ubuntu 12.10
N2100
SBX
GNU Radio 3.7.2.1
UHD 003.006.002-1
I have been trying to set up a video link (loop back cable) using named
pipes but am stuck with a crash.
It works until I introduce the USRP into the loop. Though it is the same
set up I use to transmit I text file without trouble.
What I have done:
VLC - Named Pipe - VLC
(fail) - found reference to VLC bugs in forums so gave up on that
VLC - Named Pipe - Mplayer
(works)
VLC - Named Pipe 1 - File Source GRC - File Sink GRC - Named Pipe 2 -
Mplayer
(works)
VLC - Named Pipe 1 - File Source GRC - OFDM MOD - OFDM DEMOD - File Sink
GRC - Named Pipe 2 - Mplayer
(works)
Now with hardware:
VLC - Named Pipe 1 - File Source GRC - OFDM MOD - USRP Sink- USRP -Source -
OFDM DEMOD - File Sink GRC - Named Pipe 2 - Mplayer
(FAILS!!). Reports: Segfault (core dumped). GRC file is running, VLC is
streaming. Fail occurs as soon as I open Named Pipe 2 with Mplayer
However, this is the identical GRC - USRP setup I use to repeatedly
transmit a text file successfully.
I have no reason to believe the UHDlib is failing, the segfault I think is
a python crash?
The parameters I am using:
VLC:
cvlc v4l2:///dev/video0 :v4l2-width=160 :v4l2-height=120
:v4l2-aspect-ratio=4/3 --noaudio
--sout=#transcode{vcodec=h264,vb=1024}:file{dst=./txPIPE.ts} :sout-keep
USRP:
sample rate 12.5M
GRC: - not sure of the impact of these settings
These are the ones I am not so sure of:
File source, repeat yes or no?
File Sink, unbuffered on or off? append file on or off?
I am guessing my problem is related to sample rate, buffer sizes, frame
rate etc. I have tried a few permutations without luck though, but not
everything.
I have not set camera fps -
*v4l2-fps float*I have hoped the data flow back pressure would be dealt
with by perhaps VLC with default setting (zero)? Or I'd just miss frames on
reception?
Just looking for some suggestions here I as I have put a good bit of time
into this now without luck
regards
Alexander Buckley
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
