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.

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.

Well, you must somehow know the public key of the person you want to chat with. The important feature is that everyone is allowed to see this key. So you can have a trusted network that allows you to build a database of public keys of important people.

Look up public key cryptosystems. A worthwhile read, the entire internet is built on this technology.

https://en.wikipedia.org/wiki/Public-key_cryptography