# Piped Video Streaming Crash

**URL:** <https://www.ruby-forum.com/t/piped-video-streaming-crash/239486>\
**Category:** GNU Radio\
**Created:** [February 28, 2014, 6:26pm UTC](https://www.ruby-forum.com/t/piped-video-streaming-crash/239486 "2014-02-28T18:26:31Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Detlef\_R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/58f4c7/32.png) [@Detlef\_R](https://www.ruby-forum.com/u/Detlef_R)\
**Post date:** [February 28, 2014, 6:26pm UTC](https://www.ruby-forum.com/t/piped-video-streaming-crash/239486/1 "2014-02-28T18:26:31Z")

</div>

Hi Marcus

Hopefully your seeing this, for some reason that other  
thread[http://lists.gnu.org/archive/html/discuss-gnuradio/2014-02/msg00351.html](http://lists.gnu.org/archive/html/discuss-gnuradio/2014-02/msg00351.html)is  
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