Hacker News Reader

Comment by guitarbill | Hacker News Reader

Even the best video conferencing software (codecs, etc) is no match for an unreliable network with zero latency guarantees. Otherwise we would have done this already. But you can't buffer video calls.

Who knows, maybe with net neutrality gone ISPs will provide priority traffic so companies can pay more for better video conferencing (whatever better means). And rich people can pay for better Netflix. We can dream and look on the bright side, right? I just hope you aren't a video conferencing startup, because $megacorp already has an exclusive with the ISPs for video conferencing on this priority network...

(On a serious note, I mention this because it's part of the age-old network traffic prioritisation debate, not to start a flame war about net neutrality. That includes the downside of prioritisation, too)

View on HN

No, don't blame this on net neutrality. Skype used to be great, even for vidcalls - maybe not conferencing, but was tolerable - when it was pre-M$ and when it was p2p.

The thing that is destroying video calls is making them going through a centralized system; that's a delay and 2x bandwith for everyone.

This is not a net-neutrality thing.

> No, don't blame this on net neutrality.

I never said that. I agree it's more fundamental than that, since TCP/IP (and UDP) make no latency guarantees. (I also happen to live in a country unaffected from the situation in the US, so it is just a gedankenexperiment for me)

> The thing that is destroying video calls is making them going through a centralized system

There are many things that destroy video calls. Inadequate bandwidth. Terrible WiFi hardware (LTE/4G has worked better for me in several cases). Centralized system can even provide a benefit. Users of Teamspeak or Ventrilo might remember how much they outperformed P2P in an age of very limited bandwidth (given the server had adequate bandwidth).

So shouldn't WebRTC be more awesome then?

http://peerjs.com/

There's still unfortunately some sizeable gaps in implementation[0].

[0]:http://caniuse.com/#feat=rtcpeerconnection

Okay but on the browsers where it's implemented well, it is awesome?

It's not like Skype is designed to run on many architectures per OS either. Just pick one and use it!

My question though -- does WebRTC have better quality videoconferencing than Skype and Hangouts right now on the best browser implementation?

> Not to start a flame war about net neutrality

Too late!

I've never been convinced that lack of prioritisation is the real obstacle to videoconferencing. It's usability. The only videocall application that's ever achieved decent popularity seems to be FaceTime.

Mind you, one-way videoconferencing is becoming very popular these days in the form of "streamers".

There are also non-technical usability questions - like phones, the social cues are subtly different to same-room conversations, and potentially frustrating when it comes to the delicate dance of getting the other person to let you talk.

The only? People still use the word "Skype" as a general term for video calling.

> Mind you, one-way videoconferencing is becoming very popular these days in the form of "streamers".

Streamers are normally not real time, there's a large delay, meaning lots of time to buffer!

FaceTime works well, but only between two parties. Skype used to work well, but has inexplicably gotten worse - anecdotally of course.

> I've never been convinced that lack of prioritisation is the real obstacle to videoconferencing.

I'm not saying the lack of prioritisation is why it fails, or that prioritisation will fix everything. But lower latency and higher bandwidth doesn't seem to hurt. Going from 100Mbps to 1Gbps made a huge difference. And 1Gbps isn't that much, you can now get it some residential areas in the UK for a very reasonable £63 (about 80 USD) per month.

Again UK specific, but some ISPs have much, much better routing than others (even with "net neutrality"). Of course, in the UK ISPs have to do various government filtering, which probably adds several milliseconds...

Sounds like an idea for an app: each side of the call gets 60 seconds to speak, then is automatically muted and the other side opened. Or do it the speed chess way and have a button you press when you're done with your thought so you can "bank" time for a later point of conversation.

Sounds fun. We can pretend we're in The Expanse, and we have to deal with the communication lag between Earth and Mars or the Belt.

Replace the button with voice recognition and let the people say "over" when they're done talking.

Dropped calls every time you utter the word "over" don't sound like a usability enhancement

Hmm. With decent enough speech recognition machine learning (!) you could have the system act as "chair" and decide who it thinks should be speaking, with appropriate UI cues.

Quite tricky as you have to interpret non-speech vocalisations.

so...Snapchat?

If snapchat was a continuous stream like a skype meeting, yes

> is no match for an unreliable network with zero latency guarantees

UX is a disaster. At least they could display latency / packet loss charts for both directions. Volume gauges. Warnings on audio feedback or high compression.

We spend too much time asking if volumes and quality are ok.

> We spend too much time asking if volumes and quality are ok.

I agree, but that happens on teleconferences using phonelines, too. So not really a video conference only thing.

I'm not sure if all those problems are truly UX only problems though. How useful is an n-way latency graph Volume gauges, I see that more as a hardware fault. When using a phone or an iPad, that question never comes up. Audio feedback, IMO hardware/driver issue. Again, speakerphone is okay. High compression is obvious from the blockiness.

> that happens on teleconferences using phonelines

Phonelines do not have packet loss, latency and volume auto adjust issues. And a big screen that can fit a couple of gauges.

> High compression is obvious from the blockiness.

Not when you are the sender - and not when you are using audio only.

> you can't buffer video calls

FaceTime's "pause" of the video is one option. Software on both ends should keep a few user-selectable "keyframes" and display them when they drop to only audio.

Reply on news.ycombinator.com