I think for a home user or smaller setup where you don't need multicast, you could easily go down the router of tvheadend. Has a nice interface to manage everything too.
This very cool I will do a test with a USB3 camlink capture card and the udp proxy solution on the RPI4 - also I will avoid the unicast/multicast - I did not have any luck with ffmpeg and rtmp so maybe this will work for me ;)
Very nice videos, great work. I was wondering if instead of udproxy can someone use socat to tunnel UDP from one device to another and then access it on the second from the loopback
Hey thank you for your video , but can you give a basic explanation of what do you need as a minium specs to run Multicast on your home network ? thank you
Nice series. I would like if you could show if there is an good way to relay for example a cctv camera stream in the multicast server. And also if there are any way of displaying this like a tv box. Kodi maybe?
I do something similar with an online radio station (TCP), where I just use cvlc to restream it here as multicast, and it's part of the channels on my SAP server
I would appreciate a video where you tell us how you make initial video files to be streamed. There are a lot of issues when you make a playlist: stuttering, jitter, sound disappearing after another file was added to the stream. How do you solve it?
Do you have a way you can do this with a type-m cablecard? I was unable to find a linux supported cablecard tunner. Could I use an HDHomerun with a cable card over ethernet?
Hi , on minute 4:37 , when you try to route all multicast to the loopback , I have made the exact same configuration and when i start dvblast and check on the remote client i still see the udp traffic flooding my network , and i'm not requesting any stream for it , so it is not being stopped by the route ...can you test this ? thank you
Just for a future question i found the solution , the way you show on the video at the config for the dvblast you are not defining the IP for from where you want that stream to go , and it will default to the eth0 address . to achive what you have wanted you neet to put like this eg: 239.1.1.11:20000@127.0.1.1 1 1101 # R 239.1.1.12:20000@127.0.1.1 2 1102 # R .... Where 127.0.1.1 is my lo:1 interface . Now it works
Doesn't just the Pi still put out multicast data, just to the loopback interface and not the network? So, the Pi is still doing double the work right - once for loopback and once for TCP? Or have I misunderstood it?
Quick question: all of this is very interesting and I would be somewhat interested in replicating this, however, I have one question, do you happen to know if this method is compatible with the standards used in the US for over the air TV? -Thanks
Toby Cowles I’m in the US and hope to try this on a limited basis at home. I think the main deal is that the tuners have to be compatible with US digital over the air broadcasts, rather than the standards used in Australia, NZ, the UK or EU. All the network plumbing is the same.
Excellent content mate , nothing better than RPIs and networking gear, thanks for making my Sunday more interesting! 👍👍
Your videos are always excellent. Thank you.
I think for a home user or smaller setup where you don't need multicast, you could easily go down the router of tvheadend. Has a nice interface to manage everything too.
Mate, you’re smashing out the videos. Thanks 👍
Thanks mate. I'm on a bit of a roll at the moment.
This very cool I will do a test with a USB3 camlink capture card and the udp proxy solution on the RPI4 - also I will avoid the unicast/multicast - I did not have any luck with ffmpeg and rtmp so maybe this will work for me ;)
Very nice videos, great work. I was wondering if instead of udproxy can someone use socat to tunnel UDP from one device to another and then access it on the second from the loopback
Awesome Job Sir.
Had nothing to say, so just thumbed up some comments and your video
Mate, that's the best comment yet! Cheers :)
Loving these videos. Thanks. Would it be possible to use this setup to stream pay TV satellite channels to clients on your local network?
Hey thank you for your video , but can you give a basic explanation of what do you need as a minium specs to run Multicast on your home network ? thank you
Nice series. I would like if you could show if there is an good way to relay for example a cctv camera stream in the multicast server. And also if there are any way of displaying this like a tv box. Kodi maybe?
I do something similar with an online radio station (TCP), where I just use cvlc to restream it here as multicast, and it's part of the channels on my SAP server
great video, how many clients can be connected at the same time? thanks.
This is great. Just one question, is there a way to do it with the source being free to air satellite? Pardon if the jargon is incorrect.
Should be. Just swap dvb-t for dvb-s and the rest should be the same. I haven't done any satellite setup though.
I would appreciate a video where you tell us how you make initial video files to be streamed.
There are a lot of issues when you make a playlist: stuttering, jitter, sound disappearing after another file was added to the stream. How do you solve it?
Do you have a way you can do this with a type-m cablecard? I was unable to find a linux supported cablecard tunner. Could I use an HDHomerun with a cable card over ethernet?
great video. Where can I learn more about it
FYI 1.2.3.4 isn't a private IP, you should be using an IP that isn't on the net.
I know, I just do things like that to upset the Internet :)
Great stuff !!!!
Hi , on minute 4:37 , when you try to route all multicast to the loopback , I have made the exact same configuration and when i start dvblast and check on the remote client i still see the udp traffic flooding my network , and i'm not requesting any stream for it , so it is not being stopped by the route ...can you test this ? thank you
Just for a future question i found the solution , the way you show on the video at the config for the dvblast you are not defining the IP for from where you want that stream to go , and it will default to the eth0 address .
to achive what you have wanted you neet to put like this eg:
239.1.1.11:20000@127.0.1.1 1 1101 # R
239.1.1.12:20000@127.0.1.1 2 1102 # R
....
Where 127.0.1.1 is my lo:1 interface . Now it works
Doesn't just the Pi still put out multicast data, just to the loopback interface and not the network? So, the Pi is still doing double the work right - once for loopback and once for TCP? Or have I misunderstood it?
The network interface (with its limited speed and sharing of the USB) doesn't have to deal with it though.
Nice video thnks
It's possible to make like a local clustering server to serve more clients?
Quick question: all of this is very interesting and I would be somewhat interested in replicating this, however, I have one question, do you happen to know if this method is compatible with the standards used in the US for over the air TV? -Thanks
Toby Cowles I’m in the US and hope to try this on a limited basis at home. I think the main deal is that the tuners have to be compatible with US digital over the air broadcasts, rather than the standards used in Australia, NZ, the UK or EU. All the network plumbing is the same.
how does udpxy know about the multicast groups? was the config file in a place that udpxy knows about? or is it a function of multicast?
udpxy takes it "config" from the client requested URL. So in this case /udp and /multicast:port... the readme has a better explanation for this.
All of these topics you already covered in different videos two years ago.
Arindam Ghoshal
Yeah...but now we have all together and is much easier to follow.
I wish linux had an interface and not a command line style stuck in the 70's...
co ty pierdolisz
Can't tell if you're being serious or not.