31–40 of 64 posts
Related question: why does Netflix provide a so much better video streaming service than a short-distance VoIP session? (I say short-distance because Netflix obviously uses a content distribution network of some kind; not taking this into account would make the comparison unfair).
E.g. you couldn't buffer 5 seconds.
Not enough IPv4 addresses.
Related question: why does Netflix provide a so much better video streaming service than a short-distance VoIP session? (I say short-distance because Netflix obviously uses a content distribution network of some kind; not taking this into account would make the comparison unfair).
Because having a VoIP call is like producing a Netflix movie .1 seconds before screening that movie. E.g. you couldn't buffer 5 seconds.
Related question: why does Netflix provide a so much better video streaming service than a short-distance VoIP session? (I say short-distance because Netflix obviously uses a content distribution network of some kind; not taking this into account would make the comparison unfair).
Because having a VoIP call is like producing a Netflix movie .1 seconds before screening that movie. E.g. you couldn't buffer 5 seconds.
Low-latency packet video can work incredibly well over a dependable network connection (with a known constant throughput and no jitter), low end-to-end per-packet latency, and good isolation between everybody's microphone and speaker. This was mostly solved in the 1990s. A lot of what makes Skype/Facetime/WebRTC/Chrome suck are the compromises and complexity inherent in trying to do the best you can do for when these…
Noob question: Where do you think Google's BBR https://ai.google/research/pubs/pub45646 and CMU's HFSC https://www.cs.cmu.edu/~hzhang/HFSC/main.html fall short?
--
For folks unaware, Keith created https://mosh.org and is an expert in Computer Networks.
Here's a relevant talk by Keith on Sprout, a new transport protocol for live video on noisy cellular networks that uses probabilistic inference to predict congestion; and Remy, a program that generates transport protocols on-the-fly in response to network conditions: https://youtu.be/UsCOVF0vDe8
And here's a talk at Usenix on Salsify: https://youtu.be/LPj2ffe7Isk news.yc discussion: https://news.ycombinator.com/item?id=16964112
UoCambridge's David McKay on Information Theory, Pattern Recognition, and Neural Networks : https://videolectures.net/course_information_theory_pattern_...
Related question: why does Netflix provide a so much better video streaming service than a short-distance VoIP session? (I say short-distance because Netflix obviously uses a content distribution network of some kind; not taking this into account would make the comparison unfair).
$ ping google.com.au PING google.com.au (216.58.196.131) 56(84) bytes of data.
64 bytes from syd15s04-in-f3.1e100.net (216.58.196.131): icmp_seq=1 ttl=51 time=3239 ms
64 bytes from syd15s04-in-f3.1e100.net (216.58.196.131): icmp_seq=2 ttl=51 time=4524 ms
64 bytes from syd15s04-in-f3.1e100.net (216.58.196.131): icmp_seq=3 ttl=51 time=4434 ms
64 bytes from syd15s04-in-f3.1e100.net (216.58.196.131): icmp_seq=4 ttl=51 time=3622 ms
64 bytes from syd15s04-in-f3.1e100.net (216.58.196.131): icmp_seq=5 ttl=51 time=1022 ms
64 bytes from syd15s04-in-f3.1e100.net (216.58.196.131): icmp_seq=6 ttl=51 time=849 ms
64 bytes from syd15s04-in-f3.1e100.net (216.58.196.131): icmp_seq=7 ttl=51 time=1030 ms
64 bytes from syd15s04-in-f3.1e100.net (216.58.196.131): icmp_seq=8 ttl=51 time=974 ms
64 bytes from syd15s04-in-f3.1e100.net (216.58.196.131): icmp_seq=9 ttl=51 time=897 ms
64 bytes from syd15s04-in-f3.1e100.net (216.58.196.131): icmp_seq=10 ttl=51 time=1022 ms
64 bytes from syd15s04-in-f3.1e100.net (216.58.196.131): icmp_seq=11 ttl=51 time=1008 ms
64 bytes from syd15s04-in-f3.1e100.net (216.58.196.131): icmp_seq=12 ttl=51 time=949 ms
64 bytes from syd15s04-in-f3.1e100.net (216.58.196.131): icmp_seq=13 ttl=51 time=871 ms
64 bytes from syd15s04-in-f3.1e100.net (216.58.196.131): icmp_seq=15 ttl=51 time=1103 ms
64 bytes from syd15s04-in-f3.1e100.net (216.58.196.131): icmp_seq=16 ttl=51 time=1005 ms
64 bytes from syd15s04-in-f3.1e100.net (216.58.196.131): icmp_seq=17 ttl=51 time=830 ms
64 bytes from syd15s04-in-f3.1e100.net (216.58.196.131): icmp_seq=18 ttl=51 time=752 ms
64 bytes from syd15s04-in-f3.1e100.net (216.58.196.131): icmp_seq=19 ttl=51 time=703 ms
64 bytes from syd15s04-in-f3.1e100.net (216.58.196.131): icmp_seq=20 ttl=51 time=899 ms
64 bytes from syd15s04-in-f3.1e100.net (216.58.196.131): icmp_seq=21 ttl=51 time=821 ms
Does this answer the question? =)
Related question: why does Netflix provide a so much better video streaming service than a short-distance VoIP session? (I say short-distance because Netflix obviously uses a content distribution network of some kind; not taking this into account would make the comparison unfair).
But the internet can, at its core manage packet delivery within the delays required for real time communication.
More precisely the issue is probably one of supply and demand; that our internet is tuned for content to radiate out from large scale producers of content, flowing down to its consumers. There's far less capacity and focus "laterally" in the network -- between consumers and other consumers -- as is required by VoIP sessions.
Aspiring youths see this market ripe for disruption, and next year there are N+1 video-conferencing solutions, all of them rather shit.
The biggest challenge doesn't seem to lie in the actual video quality. The problem is in getting the damn call up in the first place, with all participants seeing and hearing all other participants.
Low-latency packet video can work incredibly well over a dependable network connection (with a known constant throughput and no jitter), low end-to-end per-packet latency, and good isolation between everybody's microphone and speaker. This was mostly solved in the 1990s. A lot of what makes Skype/Facetime/WebRTC/Chrome suck are the compromises and complexity inherent in trying to do the best you can do for when these…