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 C.'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

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs