discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Help with video link


From: Alexandru Csete
Subject: Re: [Discuss-gnuradio] Help with video link
Date: Thu, 27 Mar 2014 16:47:16 +0100

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 <address@hidden> 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 <address@hidden> 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 <address@hidden>
>> 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
>> > address@hidden
>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >
>
>
>
>
> --
> Alexander Buckley
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]