From The Neuros Technology Wiki

Jump to: navigation, search

If you want to stream the live feed from your Neuros OSD to your PC, read on.

Please Note that this is for Arizona images only. TORFU is no longer officially supported by me and the streaming server won't work with it

StreamFuse may already be included in your firmware version, but it is very likely that the version on this Page has some features that have not yet been merged into the original firmware.


What is stream_fuse

  • A filesystem and server that sends the video feed from the OSD over a network connection (either LAN, Wireless LAN or Internet), similar to functionality found in the Slingbox(r)
  • You can watch the video signal that is received by the OSD on your PC
  • You can use standard video players that are able to decode ASF (MPEG4 Simple Profile) over a HTTP Stream

Installation Instructions

Fortunately this is already very simple.

  • Download the file stream_fuse [1] to your PC.

Please no longer use the files from svn. They will be broken most of the time!

  • Put it on a Memory card, USB Stick or Network Share
  • Create the /media/ext/users and /media/stream directories if they do not already exist
  mkdir /media/ext/users
  mkdir /media/stream
  • Copy the file from <where you put it> in the directory /media/ext/users

for example

  cp /media/USB/stream_fuse /media/ext/users
  • Make the the file executable
  chmod 0755 /media/ext/users/stream_fuse
  • If you are upgrading from an earlier version make sure to delete the files passthru and stream_fuse in /mnt/OSD
  rm /mnt/OSD/passthru
  rm /mnt/OSD/stream_fuse
  • Run the server
  /media/ext/users/stream_fuse /media/stream
  • If you want to automatically start the server at system startup add the following lines to /mnt/OSD/
  mkdir /media/stream
  sleep 10
  PSENTRY=$(ps ax | grep stream_fuse | grep -v grep)
  if test -z "$PSENTRY"; then
         /media/ext/users/stream_fuse /media/stream 

HTTP Authentication

You can restrict access to your stream by protecting it with a user and password. First find a way to encode a Base64 String. Either online i.e. [2] or by using some base64 encoding tool).

You need to encode the string


To enable, the authentication execute the server as follows

  /media/ext/users/stream_fuse /media/stream -- --basic_auth <your_base64_string>

For example when using username: user and password: test the commandline would look like

  /media/ext/users/stream_fuse /media/stream -- --basic_auth dXNlcjp0ZXN0

Seems that i have made a mistake. Since Rev. 456 you use the whole string (including any = or == ).

If you don't know what base64 encoding means follow these steps:

  • Go to this url
  • Enter the string user:password in the text area. (where user is your desired username and password your desired password)
  • Press 'Convert the Source Data' (Leave all other settings alone)
  • Copy the created string and use it in your stream_fuse commandline (as stated above)

Advanced Configuration

You can change the behavior of the Server through a control interface. (since Rev. 456)

  • Set Authentication Password
  echo "SET_AUTH <base64_string>" > /var/run/stream_fuse.cmd
  • Disable Authentication
  echo "SET_AUTH none" > /var/run/stream_fuse.cmd

Note: These settings are runtime settings and not permanent. After the next reboot they are gone.

Watching the Stream

Currently there are two known programs that work with the streaming server (but others may work too):

  • mplayer [3]
  • VLC (Video Lan Client) Media Player [4]

Instructions for mplayer

Connect to the server by running

  mplayer http://<osd_ip>:10001/<profile-number> -cache 2000

profile-number is a Quality profile that determines the Resolution and Bitrate of the stream. Currently supported profiles range from 1-5 The caching is not mandatory but strongly recommended

Instructions for VLC

  • Select File->Open Network Stream

Open Stream

  • Select HTTP/HTTPS/FTP/MMS and in the URL Field enter http://<osd_ip>:10001/<profile-number>

For information about the profile-number read above in the Instructions for mplayer Under Advanced options select caching and enter 1200 (milliseconds)

Select Stream

The caching is not mandatory but strongly recommended

Note: If you want to keep the information of the connection in vlc, just save it as a playlist and rename it with a .vlc extension.

Quality Profiles

Note: This mapping seems to change from release to release in an upredictable manner. I have currently no way of determining which values map to wich settings, so you have to just try them and find the one that suits your needs.

Profile Number Resolution Video Bitrate Audio Bitrate FPS
2 640x480 2 96 25
3 320x240 2 96 25
4 640x480 2 96 25
6 352x288 2 96 25
7 640x480 11 128 25
8 352x288 6 96 25
9 352x288 11 128 25
11 320x240 2 96 30
12 640x480 3 96 30
14 352x288 6 128 30
15 640x480 11 128 30
-1 Test the error stream 0.25

Manual Quality Settings

If you are not satisfied with the predefined quality profiles, you can specify your own quality settings through the URL.

  R ... Resolution  (3 = 640x480, 4=352x288)
  F ... Framerate  (13 = 25fps; 18 = 30fps)
  V ... Videobitrate (0 = 250kbps, 1 = 512kbps, 2 = 768kbps, ...)
  A ... Audiobitrate (0 = 64kbps, 1 = 96kbps, 2 = 128kbps)

Note: Not all settings can be used together, but i currently have no information on that, so you have to figure the working combinations out yourself.

Automatically switching to a channel

If you have your IR Blaster setup correctly you can specify the channel you want to watch through the Request URL by appending "/channel/<channel-number>".

  mplayer http://<osd_ip>:10001/<profile-number>/channel/<channel-number> -cache 2000

This will switch to the <channel-number> before the streaming starts. This feature has been implemented in Rev. 507 and was tested with Firmware Version 3.33-2.09-00.871.

Watching a Stream on the OSD

DO NOT TRY TO SEEK WITHIN THE STREAM NOR TRY TO FAST FORWARD. This will freeze your OSD requiring a reboot (i am working on this)

Please consider this feature highly expiremental and unstable. I won't officially support it until it is in a more stable state. But for the neuros developers and very experienced users i will provide information on how you can test it.

  • First make sure that you are using the latest version of stream_fuse
  • When the server is running you can tell it the location that you want to stream by writing a command to the control pipe
  echo "HTTP_GET <stream_host> <port> <path>" > /var/run/stream_fuse.cmd
  stream_host is the ip address of the streaming server (i.e. your pc)
  port        is the port of the streaming server (for vlc this would be 8080)
  path        is the url path of the streaming source (normally this would be / )

Note: It currently does not support host names, you MUST specify an ip address

  • If you are streaming from vlc to the OSD this would be for example
  echo "HTTP_GET 8080 /" > /var/run/stream_fuse.cmd
  • Once you have told the server where it can get the data you can play the file stream_in.asf in the streaming directory.

For example

  vplayer --path /media/stream/stream_in.asf
  • You will have to wait several seconds before the stream starts playing because the buffer has to be filled.

VLC settings

I've only tested streaming from vlc to the OSD. You can get good results by starting vlc with the following parameters

  vlc  <filename> --sout '#transcode{width=320,height=240,vcodec=DIV3,acodec=mpga,vb=512,ab=96}:standard{access=http,mux=asf,dst=}'

It is probably best if you stop the stream you've just created and immedialty start it before you hit play on the OSD

Note: For now you should make sure that your quality settings of the stream are really low, because i haven't tested anything else and it is really some work in progress.

I will update this section with information on what encapsulation format works best and what vlc settings should be used


  • Help, I can't connect!

Are you sure you started the streaming server and/or you made both files executable. Are you sure that passthru is in the correct path

  • I can connect but mplayer disconnects after buffering 0.00%.

Most probably the recorder did not start fast enough to send the stream in time. The simplest solution is to wait a few seconds and try it again. If it still doesn't work, look at your TV and make sure that the OSD is not complaining about Video input.

  • I wanted to connect with a second client but nothing happens.

That's not a bug, that's a fact. You can only connect with one client at a time. If i'm going to implement RTP Multicasting then you will be able to use more than one client.

  • I get a video stream with an error message

Error Stream

If you get this error message there may be a problem with the recorder. It probably requires some user intervention on the OSD.

How it works

The core of the streaming is the fact that the OSD can save ASF files which are pretty convenient for streaming. Additionally the OSD writes the header in a way that during the recording process a "streaming header" is already available and once it is finished the header is overwritten with the correct one.

ASF structures the data in data packets that are interleaved in the file. These data does not change when the recording is finished. Only a few bytes in the header are changed (Size, Data Packet count, ...), and indexing information is added at the end of the file. So as long as the decoder get's all the data packets it can decode the stream even without knowing the complete file.

Some Neuros hackers already discovered this, and created a way to stream an unfinished file to the decoder [5] .

The only disadvantage (if any) is that a real file is written on your OSD requiring the user to have enough storage in the OSD or Network Share.

The solution to this is the stream_fuse hack described in this page. It is a "virtual" filesystem which appears to the OSD as a normal storage medium. But the difference is that no actual data is written to the storage, it immediately get's sent over the Network. After some Connection handling and the automated starting of the recorder the data is directly sent from the write calls to the filesystem over the Network to your PC. This should also reduce the Performance impact on the OSD because the recorder is a very resource hungry application leaving not much room for other applications. Even the buffering of the data so the writing and the sending process can be decoupled is too much overhead and results in buffer underruns on the client and in frame drops.

Thus the sending process is somewhat difficult, but it is optimised as much as possible allowing you to even watch the stream at the highest resolution if your network is fast enough (don't try this over wireless connections :) )

  1. Wait for an HTTP Request on port 10001
  2. Once the request is received, decode the Request and set the quality parameters according to the selected profile
  3. Immediately start the recorder and tell him the storage location and the quality settings
  4. Wait 4 seconds with the HTTP reply. ( I know this is not nice, but the recorder takes really long to start and without this stalling mplayer would disconnect because he believes that no data is coming, this will be improved in the future)
  5. Now the server is in buffering mode (the slow one) which is needed to access and decode the data
  6. Once the header is read the sending thread makes a handover to the filesystem which enables the filesystem part of the server to directly send the data over the network
  7. When the user disconnects the filesystem forces the recorder to exit
  8. After a 3 Second pause where everything is reset, you can reconnect


This is the place where users of stream_fuse can put their Feedback

Development Roadmap

The current release is Rev. 507

What you can expect from the streaming server and what is already accomplished.

I'm trying to keep the development process as transparent as possible. So you all know what i'am currently working on and thus will be released in the near future. I will also mention the users who request features in this list, even after those features are implemented. So if you find that feature XYZ is great you can thank the user who requested it.

Features already implemented

  • Streaming from the OSD (this is the core feature :) )
  • Automatically start the recorder to generate the streaming data
  • Automatically setting the recording parameters
  • Specifying different quality settings over the stream URL
  • Command Line help and passive argument checking
  • More Quality settings (with higher framerates too) (since Rev. 446)
  • Make everything work from the /media/ext/users directory (requested by nerochiaro) (since Rev. 446)
  • Stability improvements. The server now handles errors with the recorder more smoothly (since Rev. 446)
  • An error stream is sent that notifies the user if something went wrong (since Rev. 447)
  • Basic HTTP Authentication (since Rev. 448)
  • Change the Authentication while the server is running (since Rev. 456)
  • Allow the user to manually specify the quality settings (since Rev. 457)
  • First HTTP Streaming Client - warning this is currently alpha stage (since Rev. 457)
  • Smart Start part 1 (since Rev. 465)
  • Several changes to the Streaming Client (since Rev. 471)
  • Added channel changing support (since Rev. 507)

Features currently in the works

  • Streaming to IPhone/Ipod (That's a tough one, and there is no guarantee that it will even work. But i'm trying. All other points are delayed until this one is either done or definitely impossible)
  • Command pipe for interacting with the streaming server (/var/run/stream_fuse.cmd) (delayed until iphone streaming is finished)
  • HTTP Streaming client (delayed until iphone streaming is finished)
  • Code cleanup, bugfixing, code structuring (delayed until iphone streaming is finished)
  • SmartStart part 2 (will be explained once it is implemented ;) ) (delayed until iphone streaming is finished)
  • Make the connecting more reliable (especially when using mplayer) (closely related to SmartStart) (delayed until iphone streaming is finished)

Planned Features

This list is not ordered by importance

  • Receive RTP Streams
  • OSD to OSD Streaming
  • Preventing the user from mounting over important directories
  • Prevent streaming if a recording is running
  • Send RTP Streams (this will probably not going to be implemented)

Requested Features

You can add features that would be great to have

  • Allowing the user to safely stop the server (requested by jsdf, alekseyz)
  • GUI instructions and manipulation of stream_fuse (requested by jsdf). This may be done in conjunction with the Neuros designer.


Thanks to greyback for his passthru and channel tools.

Thanks to bagster, jsdf, nerochiaro, and everyone i've forgotten for testing.

Personal tools