31–40 of 40 posts
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).
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.
Contrary to what other commenters suggest, a proper stream cipher like ChaCha20 is not even needed. You could just use CTR mode, which turns any block cipher (like AES) in a stream cipher and prevents ciphertext bit errors from creating more plaintext bit errors. Also, transmit the counter every once in a while so that dropped packets don't prevent you from decrypting subsequent packets.
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.
Hopefully things have structured such that 802.11 packets are divisible by video frames.
Earlier quoted context omitted.
encrypt with a redundant parity data?
How would you implement analog parity? Parity doesn't translate well as a concept into the analog space. You can take an analog signal and "quantize" it into sixteen possible values so that you can apply a parity algorithm that returns sensible results and doesn't fail with expected noise, but you're digitizing the signal.
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
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!
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…
On the opposite end you've got streaming video or even many common formats and settings for ripped/downloaded video. Those do a keyframe every (x) frames and then between keyframes the file only contains the data for changes to the keyframe. This gets you smaller files so your downloads are quicker and your streams look nicer while using less bandwidth.
I know there's a lot more to it but at least with locally stored files, I thought it mostly had to do with keyframes. With streaming I'd imagine it's related more to how the stream is managed to download in chunks and maximize quality versus bandwidth (rather than focusing on quick scrubbing or quick access to random points of the video).
I'm interested in this stuff so if there's something I'm missing or flat-out wrong about, feel free to educate me.
Earlier quoted context omitted.
> 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.
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.
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.
Earlier quoted context omitted.
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).
If the receiver miss a chunk of data, the stream cipher is not able to re-synchronize (as opposed to a video-stream which synchronizes on I-frames)
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…
Isn't a lot of that related to how the video is encoded/decoded though? I have only a basic understanding of how it works through working with video (not developing or tweaking actual codecs) but when I'm doing VJ-type stuff in Resolume (for example) I use a setup where all clips are encoded with a keyframe every frame. It makes for some huge clips but I can scrub or jump around or manipulate clips with no delay at a…
I doubt it's designed for the random access I'm describing, though. So, one for that might solve the problem. Might also need to be integrated with a good, storage subsystem if that causes any difficulties. Cool, though, that yours lets people jump around at will. :)
