You should first try and see if you can transmit a static file using your setup. I doubt you can without using packet encoder/decoder and some synchronizer on the RX side, though I admint I don't know if these are already contained in the OFDM blocks.
Alex On Thu, Mar 27, 2014 at 4:17 PM, Alexander Buckley <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> >> 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-gnuradio mailing list >> > [email protected] >> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > > > > > > -- > Alexander Buckley > _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
