Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wifibroadcast – Analog-like transmission of live video data

befinitiv.wordpress.com

Post reply on HN
Print view View original

21–30 of 40 posts

Re: Wifibroadcast – Analog-like transmission of live video data

#21

Post by MrRadar »

taterbase wrote: post #4
0942v8653 wrote: post #3

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.

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?)

A stream cipher like ChaCha20 would work. Most stream ciphers (including ChaCha20 and RC4) work by generating a pseudorandom bitstream based on the key which is then xor'd with the cleartext to produce the ciphertext. Since neither the cleartext nor the ciphertext are used to generate the pseudorandom bits any individual bit flip in the ciphertext will only result in that bit being flipped in the cleartext, the same as if the data were not encrypted.

Re: Wifibroadcast – Analog-like transmission of live video data

#22

Post by Animats »

nickpsecurity wrote: post #2

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. ;)

This isn't analog video. It's one-way broadcast digital video. Like current broadcast TV.

Re: Wifibroadcast – Analog-like transmission of live video data

#23

Post by nickpsecurity »

lfowles wrote: post #13
nickpsecurity wrote: post #7

Earlier quoted context omitted.

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 error…

> 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. :) Don't forget not having to rewind after watching/before watching. Glad that whole class of annoyance is gone, much more annoying than poor random access :)

That's what this meant:

"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. :)"

Re: Wifibroadcast – Analog-like transmission of live video data

#24

Post by nickpsecurity »

zdw wrote: post #15
nickpsecurity wrote: post #7

Earlier quoted context omitted.

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 error…

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 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.

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

Re: Wifibroadcast – Analog-like transmission of live video data

#25

Post by nickpsecurity »

woah wrote: post #19
nickpsecurity wrote: post #2

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. ;)

I don't think that most people need to be reminded that digital data is transmitted with electricity.

Not electricity but analog circuits. Many people think they have one or the other while they have a mix of both leaning heavily toward digital. So many misconceptions about the topic.

Re: Wifibroadcast – Analog-like transmission of live video data

#26

Post by nickpsecurity »

Animats wrote: post #22
nickpsecurity wrote: post #2

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. ;)

This isn't analog video. It's one-way broadcast digital video. Like current broadcast TV.

I know man. It's a semi-joking and semi-serious post where I point that people step from one mental, model (reliable/p2p/digital) to another (lossy/continuous/analog) to come up with a good solution to a problem. In this case, kind of reinventing one but with a medium that has plenty of cheap HW supporting it. It's technically digital but most like analog for the average person's experience with the attributes.

Re: Wifibroadcast – Analog-like transmission of live video data

#28

Post by danellis »

taterbase wrote: post #4
0942v8653 wrote: post #3

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.

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?)

How much security do you lose if you encrypt each frame individually?

Re: Wifibroadcast – Analog-like transmission of live video data

#29

Post by Dylan16807 »

caf wrote: post #20
0942v8653 wrote: post #3

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.

Encryption would work just fine if you used a stream cipher, like ChaCha20. (With a stream cipher, a single bit error in the encrypted data results in a single bit error in the decrypted data).

A block cipher doesn't make errors all that big. Look at the two layer error correction on a CD. That would play extremely well with a block cipher if you wanted to.

Re: Wifibroadcast – Analog-like transmission of live video data

#30

Post by Dylan16807 »

taterbase wrote: post #14
x1798DE wrote: post #11

Earlier quoted context omitted.

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

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 dat…

> 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.

Post reply on HN