I've worked on compressing (with x264, not the fastest but gets the file size right down) and encrypting a video stream with PGP and streaming the encrypted data via encrypted FTP from a Raspberry Pi. If I remember correctly, the lag was about 2 seconds, i.e. when pulling the power cable at 18:00:05, the server would have footage until 18:00:03. Most of that delay came from compression, since x264 looks at the next frame (so it waits a frame or two before running the algorithm) so the output is a bit delayed (can be disabled at the cost of much worse compression).

On the raspberry pi, the encryption took a fraction of the CPU that the compression needed, so yes, PGP-encrypting a video stream is relatively trivial, even if you call the GPG agent 5 times per second and do public key crypto every time (in this case it also made for a nice and robust format, you just split on the BEGIN PGP MESSAGE strings and can ignore broken frames). This can be optimized by a lot of course. An ideal case is probably to do keyring management with PGP and then use a different, meant-for-streaming format for the actual video data encryption and transfer.

Yes, it's pretty common in the modern web (search terms: ECDH, TLS). In this case it would be as fast as any E2EE connection.