USE VLC MEDIA PLAYER FOR STREAMING RATHER THAN AVCONV

[Alex Reed]

Hi,

Has anyone successfully been able to use VLC Media Player on a master computer running a version of Windows to stream video to the piwall. 

If so could I please how this process would be done. 

Thanks,

Alex

[Prohorov Nikolay]

System Windows 7 x64

"C:\Program Files (x86)\VideoLAN\VLC\vlc.exe" -v "D:\VIDEO\Madagascar.mkv" --sout #standard{access=udp{ttl=5},mux=ts{tsid=22,pid-video=23,pid-audio=24,pid-pmt=25,use-key-frames},dst=239.0.1.23:1234}" --loop --volume "512"

Info Russian PiWall

[Prohorov Nikolay]

System Windows 7 x64

"C:\Program Files (x86)\VideoLAN\VLC\vlc.exe" -v "G:\Download\test.m3u" --sout '#standard{access=udp{ttl=15},mux=ts{tsid=22,pid-video=23,pid-audio=24,pid-pmt=25,use-key-frames},dst=224.0.0.1}' --random --loop --volume 100

Info Russian PiWall

[Joshua Lopez]

Yes, it was something i decided to do for testing purposes since there isn't a large amount of code for preparing videos like the avconv method. to tell you the truth, I could never get my tile to pickup the videos with the avconv method but VLC showed me that the program works and that I can continue with other steps. One drawback to all of this is that the creators never tell you how to make the sound work. VLC is a great program if your only interested in displaying pretty pictures on the tiles without the sound, but the guys have a demonstration video that shows them using the wall with sounds. Until I can figure out a way to either get VLC to produce sound on the server end, I wouldn't use it. I thought about using a capturing device to leave the sound to a stereo system where the HDMI feed from the device I want to render images from, like say a DVD player, did look like it was going to work out either. when you go this route, the udp stream on the screens will be out of sync with the sound system so there has to be another way of making a video wall that has sounds. I wish they would divulge that information on their website, and that they had a better way of streaming the video since avconv is an absolute pain to get working, it shows that it streams, the tiles just aren't picking up the video.

[Alex Goodyear]

Hi Joshua,

We're sorry to hear that you have had trouble getting the avconv examples to work correctly. As you point out, VLC is a great program but we found that it didn't perform well when combined with our video wall solution. VLC introduced inexplicable delays, the GUI didn't provide enough options to properly control the streaming and wouldn't "remember" selected options between each video transmission and the CLI interface options were very confusing for many users. Avconv/ffmpeg, by comparison, just works.

I've been looking at you various emails and forum posts and gave the following observations ...

From the email you sent directly to piwall.co.uk, "avconv -i Desktop/supergirl-s00e01.hdtv-lol.mp4 -f mp4 -an udp://192.168.1.255:1234" there are 3 errors in this line

1. You must provide the "-re" flag before "-i" to instruct avconv/ffmpeg to transmit the data in real-time and not just blast the data out as fast as it can be processed.
2. You must use an "avi" container (-f flag) not "mp4".
3. avconv/ffmeg does not support the x.x.x.255 broadcast address which is why we included instructions for multicast addresses

From the email you sent to my place of work (CCFE), "My raspberry pi is 192.168.1.12, and my server is 192.168.1.11 and these are the commands I ran (the laptop is directly connected to the ethernet port on the pi) on the pi this is what I ran pwomxplayer --tile-code=41 udp://192.168.1.11:1234?buffer_size=6000000 on the server this is what I ran avconv -re -i supergirl.mp4 -vcodec copy -f mp4 -an udp://192.168.1.11:1234" - again there are several errors that would prevent the commands from working -

1. The pwomxplayer command requires the IP address of the slave/client Raspberry Pi namely 192.168.1.12:1234
   
2. Leave the buffer_size as "1200000B"
3. In the avconv command use "-f avi" for the container
4. Again in the avconv command, you need to transmit the stream to the slave/client not to the server itself so use IP address 192.168.1.12:1234

We didn't include instructions for sound because most video walls don't have sound. If you want sound, follow the instructions within the other thread on the forum to which you posted.

Your other comment about having a script to simplify starting many pwomxplayers has been covered several times in the forum along with some code to cut'n'paste.

Good luck with your 50 screen system.

Regards,

Alex and the PiWall team.

[Joshua Lopez]

I just got your command working, It's a little confusing that the client needs to listen to itself in the way you are instructing to build this thing. But I understand the server part in which it needs to transmit packets to the slave, basic stuff. But I am not understanding why you want the pwomxplayer to listen to itself. is it because it keeps the network quieter? less activity over the wires? Well all that is taken care of I just don't know how to multicast the thing. You didn't provide any instructions in the installation age regarding multi-casting rather than just mentioning that it was complex. The network I am working with is private so "it really doesn't matter" is digestible but it doesn't tell me what address I need to send the video to in order for all the tiles to receive the video. I was going to go in the direction of purchasing a hub since they broadcast everything that it is sent to them (layer 1 device opposed to a switch which is layer 2 since it uses MAC addresses to send information while the hub just shoots out everything) but I think that the tiles might reject it when it sees that a packet isn't meant for it and just reject it so I need to know how you guys broadcasted the video packets when avconv doesn't support the x.x.x.255 broadcast address. How did you do it.

[Alex Goodyear]

Hi Joshua,

I can assure you that we are not doing anything out of the ordinary regarding the server and client network address - that's how UDP networking works.

Don't waste your time and money on a hub - it will not do what you what want.

I don't understand your statement that we don't explain how to use multicast UDP on our installation page (http://www.piwall.co.uk/information/installation) - its basically the only method we explain. In the "Network configuration" section we give both the command line and permanent file "route add" configuration commands that you should be able to cut'n'paste. In the "Testing the software" section we use the multicast address 239.0.1.23.

Alex.

[Joshua Lopez]

alright I'm taking a closer look at it, if I'm going to configure the /etc/network/interfaces on the server's file with something like this (no gateway section)

auto eth0

iface eth0 inet static

address 192.168.1.100

netmask 255.255.255.0

and I'm assuming that the command to run in the command prompt is (I'm not sure why we are doing it this way since all of the networking attributes should be taken care of in the interfaces folder, the route should be listed as gateway in the interfaces folder, and why didn't we make the netmask in the interfaces folder match the one in the command?)

#up route add -net 224.0.0.0 netmask 240.0.0.0 eth0

and then run the avconv command but since the examples are only dealing with one tile, what address do I point it to in order for it to transmit to all of the tiles (after getting the pwomxplayer software to listen to itself). This udp broadcasting from avconv is all new to me.

I'm confused here, why are we adding a router ip address and a netmask to the eth0 interface outside of the subnet (192.168.1.0/24) in this command? is this how the broadcasting thing is supposed to work?

[Alex Goodyear]

Hi Joshua,

The "up route add -net 224.0.0.0 netmask 240.0.0.0 eth0" is part of the /etc/network/interfaces file not a command line instruction. if you want to execute it from the command line then use the "sudo route add.." command referred to earlier in the instructions - note the lack of the "up". The netmask in this route add command is specific to the multicast address range that we are declaring and nothing to do with the previous unicast netmask declaration.

The master and all the slaves use the same multicast IP address and port number - in our example 239.0.1.23:1234 even though they will all also have unique unicast addresses in the 192.168.1.??? range.

Please note that broadcast and multicast have very specific definitions when used to describe networks and should not be confused with one another.

Alex.

[Joshua Lopez]

Alright so this is what my /etc/network/interfaces file looks like

auto lo

iface lo inet loopback

auto eth0

allow-hotplug eth0

iface eth0 inet static

address 192.168.1.12

netmask 255.255.255.0

up route add -net 224.0.0.0 netmask 244.0.0.0 eth0

I rant the script /etc/init.d/networking restart, and the command line told me that it failed to bring up eth0. Is this normal? and I only have one pi right now, how do I test if the multicasting is working.

[Alex Goodyear]

Hi Joshua,

Without seeing the exact text of the error message it's hard to say what may be the problem but I'd start with a mistake you made whilst trying to cut'n'paste the route add line, the netmask should be 240.0.0.0 not 244.0.0.0.

Alex.

[Joshua Lopez]

I just fixed it (I think I did), my file on the pi reads like this

auto eth0

iface eth0 inet static

address 192.168.1.12

netmask 255.255.255.0

up route add -net 224.0.0.0 netmask 240.0.0.0 eth0

and my server pretty much says something similar

auto eth0

uface eth0 inet static

address 192.168.1.11

netmask 255.255.255.0

up route add -net 224.0.0.0 netmask 240.0.0.0 eth0

I figured it was time to run the commands given in the guide so I went to the pi and ran this command

pwomxplayer --tile-code=42 udp://239.0.1.23:1234?buffer_size=1200000B

and on the server I ran

avconv -re -i movie.mp4 -vcodec copy -acodec copy -f avi udp://239.0.1.23:1234

I ran to the screen and nothing was happening, Did I put the addresses in wrong? How do I check if this multicast thing is working? If there is anything that I am doing wrong here I don't see what it is. the network is up and running since I am able to ping the pi from the server via it's unicast ip address but I am not seeing any video.

[Joshua Lopez]

I also changed the addresses a but, I ran a netstat -g on both of them and saw that they are both members of the 224.0.0.251 group on eth0 interface so I changed the addresses in the commands accordingly and still nothing happened. This is what I ran.

avconv -re -i movie.mp4 -vcodec copy -acodec copy -f avi udp://224.0.0.251:1234

on the pi

pwomxplayer --tile-code=42 udp://224.0.0.251:1234?buffer_size=1200000B

and if it's important, these machines aren't connected to a switch or anything, they are directly connected to one another for testing.

[Alex Goodyear]

Hi Joshua,

I'm assuming that the "uface eth0 ..." typo in the server /etc/network/interfaces file was introduced when you transcribed the file from your server.

Try running the "route" command on both the master and the slave - you should see output like this ...

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.0     *               255.255.255.0   U     0      0        0 eth0
224.0.0.0       *               240.0.0.0       U     0      0        0 eth0

Right, I think I'm beginning to understand your setup a bit better now. I deduce that your master is not a Raspberry Pi and is most likely a Linux PC. A quick Google would reveal to you that 224.0.0.251 is a multicast DNS server address, so you really shouldn't just start using addresses on a whim. I seem to recall that you were able to use the UDP unicast address of the client to run the programs successfully - is that still the case using the current setup? If so, I suspect you may have a firewall enabled on your master so you will have to allow the multicast address and associated port through it.

Alex.

[Joshua Lopez]

Master server isn't a raspberry pi, It's a normal PC with a Debian Jessie installation. I only have one pi to use for a tile at the moment but this will have to do. I think I am understanding where the 239.0.1.23 address is coming from. Since you have "enabled the entire multicast range", you can send the signal to whatever address you want in that range and they will pick it up anyway? As to the firewall, I am still able to use stream the video through it's unicast ip address. So are you thinking to disable iptables (by default, iptables doesn't have any rules to begin with). What else could it be?

[Joshua Lopez]

At this point (since I have no access to my pi at the moment) I am running two debian machines virtually and these setups in the /etc/network/interfaces file are identical to the one's mentioned in a previous post. with that said, with the route portion of everything added to the file I ran the route and netstat -g command, the netstat -g command on both of them say that there is only 1 subscriber to the 240.0.0.0 address. I can ping the other and vice versa but I not only don't know why netstat isn't saying there are 2 subscribers to the address but also why when I ping the address I get nothing in response. The firewall should be open since this is debian, nothing is set in iptables by default.

Here are some screenshots of the two commands, both machines show the same results when these commands are run. I tried pining the address for the group that said it had 2 subscribers and nothing came back

http://imgur.com/W7o6Fz5,p4G0oRY

[Alex Goodyear]

Hi Joshua,

Check that the "ifconfig eth0" command on both the master and the slave displays something very similar to "UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1" as the 3rd (or 4th if you have IPV6 configured)  line down.

To execute a multicast "ping 239.0.1.23" command from the master you must enable broadcast/multicast replies from the slave first with the command
sudo sh -c 'echo 0 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts'   - note the use of the single quotes.

Let us know the results of these tests.

Alex.

[Joshua Lopez]

right now I am on the debian virtual machines and ran those commands you told me to do. I pinged the slave from the master, and the master from the slave and I got some responses, but then I pinged the 239.0.1.23 address and the command prompt just stuck there. and yes, I ran the route command and it gave me the exact same information as the text you posted. no pings from the 234.0.1.23 address but I have the same output from the route command that you did and the right contents of the interfaces file. as for the netstat -g command, is that one relevant to what we are trying to do here. My ifconfig eth0 in both instances of the debian boxes and ther pi's have broadcast and multicast enabled. right now I am no on a pi but I am getting the same routing table as you posted in a previous post.

I don't understand what is going on here, I have the same routing table as you do, I ran that command to enable responses from pings (which reverts back to 1 when you restart in debian, does it do that in the pi?) and I am not any closer to getting working I feel, but I feel that we are slowly diagnosing what the problems are and they are a great help. Is there another way to test a multicast setup without pings since these machines are going to keep reverting back to blocking them from a multicast address.

[Alex Goodyear]

Hi Joshua,

The /proc and /sys files systems are special virtual filesystem, sometimes referred to as a process information pseudo-file systems. They are created at boot time in memory and are used to influence the operation of a running kernel. The values are initialised to default values and any changes you make are not persistent.

Open 2 terminals on the slave Pi, in one window start the command "pwomxplayer udp://239.0.1.23:1234" and in the other execute "sudo sh -c 'echo 0 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts' " followed by "ping 239.0.1.23". Note:- for this to work you must also have the "lo" local loopback device declared in the /etc/network/interface file.

When I do this on my Pi slave, the replies start.

Now execute "ping 239.0.1.23" on the master PC, it should also receive ping replies.

Alex.

[Joshua Lopez]

Well I came back home to my pi, I configured everything in the network interfaces file, installed the necessary software and ran the commands explained in the installation page. the tile is now working and I can move on to more tiles. The only drawback is that there is some choppiness in the video stream (in specific parts of the video, meaning it's something going on during the conversion process, both codecs video and audio are being told to copy into the avi container and I think some files don't like that), so it's not a networking issue (I would assume so because the two machines are directly connected together. So it works kinda sorta I hope to smooth everything out in the near future and I may have more questions for you in the future since I plan on expanding this a little further.

[Joshua Lopez]

for instance, some of the parts of the video turn green, every time at the same part, and at others it blurs until the next cut-scene. Another problem I am encountering is that when I stream a file, the pwomxplayer software won't even play it. It shows signs of detection but then immediately stops and give the have a nice day prompt along with some other information. Are there just some video files that it plays better than others or is there a networking issue here.

[Alex Goodyear]

Hi Joshua,

Good to hear that the network problems have been solved.

The problems you describe with the videos sounds like stuff we've covered before in the forum.

Firstly, pwomxplayer can only play MPEG4 and H264 encoded videos - check the output from "avprobe filename" for a description of the codecs used for video and audio.
Even if your video is MPEG4 or H264, some encoders seem to use features/settings not compatible with real-time UDP data transmission. I have examined a few video files that work correctly with "avconv -re" and found that files with fps = tbr = tbn = tbc/2 work well. If your videos do not have this relationship between the values then you are better off re-encoding offline (see later) and then using this new version in real time.

The problems you describe of picture break up are typically caused by the network being unable to cope with the bandwidth required by the UDP transfers. The Pi only has a 100Mbit Ethernet port so you should ensure that there is no other network traffic being directed to the Pi which is why we recommend a private network.

If there isn't any other network traffic then you may find that increasing the kernel's network buffers may help. Run the following commands before starting pwomxplayer
sudo sysctl -w net.core.rmem_max=589824
sudo sysclt -w net.ipv4.udp_rmem_min=589824
sudo sysctl -w net.ipv4.route.flush=1

If this still doesn't help then you'll have to re-encode the video and audio with reduced quality settings...
avconv -i name.mov -vcodec mpeg4 -qscale 8 -r 25 -acodec libmp3lame fixed.avi"

Make sure you run the avconv command on a beefy machine or you will be waiting for a very long time.
The smaller the qscale value the bigger the file and less loss, I wouldn't go below 4 though.


Alex.

[Joshua Lopez]

Well, I got everything working. The bandwidth was probably being taken up by some of the codec that were being copied by avconv. all the videos have different codecs and each one transfers differently. I tried it again but this time without the audio and it played smoothly. I decided to change the codec of the audio to something a little less heavy. I went with mp3 and it all worked smoothly. the command is now

avconv -re -i <input video> -acodec mp3 -vcodec copy -f avi udp://239.0.1.23:1234

[Joshua Lopez]

The wall is now working, with sound might I add. This current demonstration only has 3 screens (I didn't have enough room on my switch for the fourth one) but it shows what I have accomplished.

https://drive.google.com/file/d/0B1XWuXCNnHUiQkdhc3dESGR5T0k/view

So what are my options on what I can use to run avconv from, I was running it from my laptop when in the demonstration video and through a typical home Cisco wireless router (to utilize the switch part), Can I run avconv from another pi? or do I need to do it from a PC?