This something that I used to do quite a bit of before I started using DLNA software. It actually is not that hard to arbitrarily setup multicast servers and listeners. The trick is understanding your network and the network configuration on your devices.
There are two different methods I've used. The second deals with the issue of multicasting when you have wireless nodes or more complex network topologies.
Lets say you have a media server (S1) on your LAN that is wired along with your WAPs. You also have a workstation (W1) that is wired and a wireless laptop (L1).
Scenario 1...
S1 would run "ffmpeg -re -i <somevideo_file> -f mpegts udp://239.0.0.1:5000"
W1 and L1 would run "mplayer udp://239.0.0.1:5000"
In this case, W1 would be able to receive but L1 might not unless your WAP has some special multicast handling settings. As I understand it, wireless devices assign the lowest priority to multicast traffic and as a result, wireless clients (which would connect at the highest rates) end up missing the packet. The reason why I said "might not" is because if L1 is on the same WAP that is on the LAN segment as S1 it will work. The problem occurs with regularity when you are several hops away from the LAN with S1 (e.g. a wireless mesh that has bridged WAPs or other LAN segments). You also will have problems with this method when you have multiple interfaces or you use bridge interfaces on S1 (that's a whole 'nother scenario that requires some additional network settings).
Scenario 2...
S1 would run "ffmpeg -re -i <somevideo_file>-f mpegts - | socat -u STDIO UDP-DATAGRAM:239.0.0.1:5000"
W1 and L1 would run "socat UDP4-RECV:5000,bind=239.0.0.1,ip-add-membership=239.0.0.1:<IP of interface you want to use> - | mplayer -"
The subtle difference here is for W1 and L1. With the socat program, you are explicitly telling the network to join a multicast group called 239.0.0.1:5000 and also telling the socat program to bind (listen) to that same address. The explicit joining of the multicast group, at least with the socat program seems to work better than scenario 1 because if there are packet transmission issues the app (mplayer) will not close too soon if no packet is received. This again is important in cases where your broadcast domain (your LAN) has asymmetric response times.
For both scenarios "netstat -g" would show W1 and L1 in group 239.0.0.1 when running.
I included the socat variant for S1 here just to show the command but that variant is no different than scenario 1. It is possible to be more directed with the send side too.
~ ~ ~
I'm demonstrating this with video files but for audio "-f mp3" would work for audio only. The ffmpeg commands here are not optimized and the quality would be horrible in most cases so they would need to tweaked for practical use.
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Keith C. Perry, MS E.E.
From: "John Karr" <brainbuz@brainbuz.org>
To: plug@lists.phillylinux.org
Sent: Tuesday, January 2, 2018 7:58:09 PM
Subject: Re: [PLUG] Multi-room audio
Will it just so happens that although I did not find the article you referenced, that is the solution I arrived at. If you want to know more, I'm giving a talk about it at Central in February.
On 01/02/2018 12:06 PM, Will wrote:
Hello,
I can't remember and I am too lazy to look up the question in the past about the multi-room audio but I hope they find this solution.
-Will
___________________________________________________________________________
Philadelphia Linux Users Group -- http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug
___________________________________________________________________________
Philadelphia Linux Users Group -- http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug