On Jan 19, 2016, at 9:11 AM, Joey <forum@xxxxxx> wrote:
>
> i stream the screen of the 2. monitor with ffmpeg / ffserver
That’s an inherently problematic way of approaching the problem.
Wifi is a terrible medium for transmitting live video, or in fact any realtime data. It’s subject to frequent timeouts, which are fine for web pages or email, where most of your time is spent reading what you downloaded, not pulling live data. And, a bit of delay is fine there, too.
The common solutions to that problem, used by the likes of YouTube and Netfix, are high compression rates and buffering. Neither solution is really open to you here.
First, high compression rates take too much CPU. (Just curious: what codec and encoding parameters are you currently using?)
Second, the lag from buffering directly fights your wish for a realtime solution. You really don’t want lags of half a second or more between mouse movements and the resulting action appearing on the projector. And half a second of buffering is on the short side of typical for such applications. Wifi security camera buffering is often more like 3 seconds, for example.
Even when all of this works, your single stream will suck up a huge chunk of the whole network’s capacity, since wifi is inherently a broadcast medium. You might be nearly monopolizing it, in many cases. (e.g. 802.11g with “54” Mbit/sec, which ends up maybe 11 Mbit/sec at the computers, which is about the data rate you should be using for screen-res video.)
If I had this problem, I’d just use a wireless HDMI transceiver pair:
https://www.google.com/webhp?q=wireless%20hdmi
Then you’re not fighting for bandwidth with other wifi users, and it’s going to be geared for near-instant transmission.
Plus, the transceiver pair is smaller and cheaper than the second notebook. :)
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
