
Wifibroadcast – Analog-like transmission of live video data - infodroid
https://befinitiv.wordpress.com/wifibroadcast-analog-like-transmission-of-live-video-data/
======
0942v8653
Does this allow encryption of the video stream? Graceful signal degradation is
a great feature, but I don't see how that would work when there is encryption.

~~~
taterbase
Encryption won't work for this scenario as it reintroduces the problem of all
or no data. Degraded encrypted data can't be decrypted successfully (yet?)

~~~
x1798DE
From my armchair position, I'd think that this is what error correcting codes
are for, aren't they?

~~~
taterbase
Error correction (or redundant parity data as est mentioned in another reply)
just kicks the can down the road.

Let's say you're using a 20/40 erasure encoding. You break a piece of data up
into 20 pieces and create 20 extra parity pieces. Now you only need 20 out of
the 40 to recreate the original data.

Are we encoding the encrypted data? Ok well we need at least 20 good pieces,
and that's to decode the original data. This method doesn't allow for seamless
degradation but allows for some data loss in the transmission (while
effectively doubling the amount we're trying to push in the first place).

Let's say we're breaking up the original data, creating parity pieces and
encrypting each little piece. Then it could decrypt each piece it got and use
it and if it couldn't decrypt a piece just throw it away. This could
potentially work but parity pieces are useless unless you are trying to
recreate the original file neglecting the ability to degrade quality. So
redundancy is more important in this scenario than parity.

But, if we make the encrypted pieces small enough, say each packet body, then
that could probably work but be resource intensive. Encode/decode every
packet, if successful insert into feed, else throw the packet away. This would
work a lot like the existing technology just requiring some middle step of
decrypting each packet body.

~~~
Dylan16807
> But, if we make the encrypted pieces small enough, say each packet body,
> then that could probably work

So in other words you can use what's basically the _default_ mode of
encryption, CBC. Each encrypted byte only depends on the adjacent 32 bytes, so
you can allow errors through and they affect a couple pixels instead of a
single pixel.

~~~
taterbase
I wasn't aware of CBC at the time of writing this comment, thanks for pointing
it out to me.

It seems if you lose any 32 bytes though you've lost the trail of encryption
as you can't decrypt any subsequent pieces.

After reading other comments I think the only reliable solution is chacha20
where each packet can be encrypted/decrypted independently of others.

~~~
Dylan16807
[https://upload.wikimedia.org/wikipedia/commons/2/2a/CBC_decr...](https://upload.wikimedia.org/wikipedia/commons/2/2a/CBC_decryption.svg)

Let's assume CBC with AES. It encrypts in 16 byte blocks. If you slightly
corrupt one block, you will fail to decrypt it entirely, and it will slightly
corrupt the block after, but everything else will be fine.

There are modes of encryption where losing one bit will corrupt all subsequent
bits.

There are also modes like GCM or stream ciphers like ChaCha20 where one
corrupted bit will not corrupt any other bits at all.

In short: There are many options, and half of them are suitable for this.

------
Yaggo
This is awesome project. I'm currently building a fixed wing drone with dual
wifibroadcast links, downstream for (stereo) video and upstream for control.

------
mintplant
> Note: Before using wifibroadcast you have to check if the regulatories of
> your country allow such a use of wifi hardware.

Any guesses as to whether this would be legal in the US?

~~~
nuand
Monitor mode is a MAC level concept, and doesn't alter any of the RF
characteristics that would make operating this device illegal. (This is not
legal advice. Consult with an attorney, etc etc)

------
lovelearning
From the advantages quoted in the article, this seems useful for recording
wifi-enabled security camera feeds too.

------
nickpsecurity
Cool stuff. Good to see them recognize and use advantages of analog. I could
tell them _digital_ transmission of data has always been done with analog
circuits but analog's invisible ubiquity is beside the point. ;)

~~~
coryrc
Amen. Now if someone could get DVDs or streaming services to offer fast-
forward and rewind that works as well as a VCR we'd be caught up to the 1980s!

~~~
nickpsecurity
Hell yes! Or even hardware acceleration for starting in random parts of videos
_on my PC_ so they don't break up and delay as often. This is the digital era.
It's supposed to work more reliably than old, analog tech. I used to be able
to stop my rewind or fast-forward on VCR within a few seconds of the target
moment with clean play. Still not reliable with digital streaming. (sighs)

Note: I do like how, even with errors, it still takes under 20 seconds for me
to get to any random part of the vid. That's an improvement over the
rewind/fast-forward speeds. :)

~~~
zdw
Modern video codecs use data in frames before and sometimes after the current
frame to compress more:

[https://en.wikipedia.org/wiki/Group_of_pictures](https://en.wikipedia.org/wiki/Group_of_pictures)

whereas analog media stored full resolution versions of every frame.

Seeking is much easier when you can pick any random location and have all the
data right there ready to use, and you don't have to backtrack and try to
recreate things from previous frames.

~~~
nickpsecurity
That's true. Hence me asking for "hardware acceleration" to improve the speed
to real-time if possible.

