Video Audio Conferencing: Codecs, Crypto, Peer Modes, RF, CU-SeeMe History... [re: Zoom’s crypto]

[grarpamp]

Various wrote:

> https://jitsi.org/

>> And this represents a very big sacrifice of resources in the connection?
>> My problem with jitsi so far has been that it does not work very well if
>> either end has a bad internet connection, which is more or less common in
>> Latin America.

>>> We hope to be layering on end-to-end encryption features, and would
>>> happily take community contributions.

> I don’t believe the encryption/decryption is all that resource intensive in
> comparison to the encoding and decoding of the video and audio streams
> themselves.
>
> We have a few features to try to deal with this, including audio-only mode
> and the ability to send lower-quality video (Low bandwidth mode)

One thing many voice and video apps get wrong is shipping with defaults set to
what in bandwidth terms effectively amounts to 4kHDR 60fps video + CDDA audio.
It cannot be made any more clear that this is completely unnecessary
for servicable comms, and does not establish good thinking or expectations.

Even just a fraction of 160x120 4-bit video and 8k audio works fine.
Wannabe conferencers today are brainwashed by BluRay and Gaming
out of what is actually possible within a 56kbps channel or less...

https://en.wikipedia.org/wiki/CU-SeeMe

All you need is just enough to lip and ear sync to the video and audio.
Cranking your codecs way down also saves you much needed bandwidth
for more peers, file transfers, messaging, signaling, integration, crypto,
other applications, etc... making world a happier place.

With as little as 1Mbps you could be conferencing 8 fully
meshed (no hub) independently encrypted peers.

If sensible defaults, and crazy minimums, aren't offered, the
promising freedoms of non-third-party-in-the-middle P2P
conferencing are that much harder to meet.



> I do know we suffer from poor performance on connections for which packet
> loss/packet drops are common.

It is nature of beasts, of time, of being confined to intermediate MAC+PHY
layers, choose your evil... TCP imparts pauses, UDP zaps the gap...
physics deny a general solution.

Explore random encrypted ultra wideband spread spectrum guerrilla RF via SDR
if you want to make use of some interesting and alternative channel physics.

Also consider routes over I2P, Phantom, Tor, and other overlay networks.



CU-SeeMe...

"The predominant objective here was to devise algorithms that would be
fast enough for real time videoconferencing on the typical Macintosh
platforms that were available in mid-1992, which mainly consisted of 68020
and 68030 based machines." -- Tim Dorcey, Cornell University.
>From Connexions, Volume 9, No.3, March 1995

"Milazzo, Paul.  Informal demonstration of dvc at the December 1991
meeting of the IETF in Santa Fe."

https://www.youtube.com/watch?v=o4h6oElcOtI
https://www.youtube.com/playlist?list=PL96B30F6A04A29427
https://www.youtube.com/watch?v=Rz-YHbQ2dA4
https://www.youtube.com/watch?v=HDBOIdmkdEw