Yes, these screens may or may not be playing the same content at a time.hippy wrote: The usual way would be to push a single stream out and then have every screen pick up that stream and output it. You can increase the number of streams up to the bandwidth available.
Do you really have or need 500 screens each showing different content ?
We may be changing videos on a daily basis. We think we can compress our videos using h.264 encoding, upload them to OneDrive and then rely on RPi to decode it using hardware acceleration. Streaming is definitely out of the picture, downloading once and playing as per schedule on each RPi sounds more economical.knute wrote: I don't know what sort of compression you've got on your video but 500 sites streaming HD takes a big pipe. Are they all viewing the same video on the same day? Can you send out tomorrow's video overnight? You can use multicast to transmit only once and all sites can receive the data. You might need a scheme to clean up any lost data but that is doable.
We have a system running in about 14 locations with a couple of hundred small computers driving some data displays. These are updated a couple of times a minute with new data via multicast. Since the update rate is high, we don't worry about the occasional lost packet because new data is sent again shortly. If your update rate is one video a day you should have no problem getting that done in a reasonable period of time within a manageable bandwidth.
Just tested a 4k video today morning - you're right. I think we may have to settle with HD videos compressed with h.264 for now.ghans wrote: No Raspberry Pi model can playback 4K video content properly. 1080P60 with h.264 is
I'm getting up to speed with multicast, but will it mean that the Pi has to receive its unique program just once from the network and download it on sd card for repeated use throughout the day?stschake wrote: You can stream it on the network with IP *multicast*. That way you only have to send one copy to the network for each unique program and your bandwidth requirements don't scale linearly with the number of Pis that need to receive the program. This is how IPTV usually works.
Sure. That might be a possible solution. But that requires additional work and has a few consequences: First of all: You can't really cache HTTPS traffic (unless you use your own PKI). In the info-beamer case, all communication to the internet always uses HTTPS for both confidentiality (e.g. you can't just see, for example, dashboard API keys that might be required on the devices to fetch additional content) and integrity (you can't just inject modified content). So you can't simply put a cache in the middle unless you either ignore or fix these issues through some other mechanism. Additionally as you said, it requires extra pieces of infrastructure or code (like the machine running the cache) and configuration to make your devices use it. The solution I posted does all that for you without requiring any additional work on your side (except enabling the feature) and devices will automatically distribute content locally if possible while still preserving the confidentiality and integrity properties of HTTPS. Basically every device is automatically the proxy/cache for every other device if it already has the content locally available. There's no explicit configuration required for that.algorithm wrote: ↑Thu Jan 11, 2018 10:40 amJust set up a local cache/proxy? Configure one RPi to download new content externally once per day and schedule all the others to download from it, on random or distributed (maybe by IP address) times during the night. Could be very simple with manual configuration pointing to your local cache or very fancy with firewall rules redirecting traffic etc.