I do not know if the Raspberry Pi is good enough to handle video encoding at breakneck speeds
No it's not, there's a popular project using the combination of Pi+wifi and while it works it is not satisfactory in terms of latency. Main reason is that the whole video pipeline and GPU of the Pi is completely closed so there is nothing in there you can optimize, your only way through that is call the provided API function to get a frame from the "black box", with unnecessary buffering. Most SoCs on popular SBCs have the same problem of either closed libs and/or unobtainium documentation.
So you say that LCD does not take picture sequentially? - Meaning controller takes whole frame into RAM, then frame miraculously in no time appears on LCD screen?
Just searched YT for Arduino LCD topic to show how LCD update happens in slo-mo:
https://youtu.be/X8syt55ITUo?t=267
That's a small, low performance SPI module, you just populate its internal buffer in the order you want and at the speed you want.
Normal fast high res displays (such as the ones with the common parallel 24bit RGB interface) of course take the data sequentially but also in order and at constant refresh rate, you can't just stop sending stuff while you wait for the next line or such, if you don't respect timings you get what is shown in the video above.
The standard way that computers and display controller boards use is to hold usually 2 full frame buffers that are sent to the screen alternatively using DMA at the screen clock aka out of sync with the incoming data so that the controller can populate the inactive buffer while the other is sent to avoid screen tearing and artifacts, but that obviously introduces 1-2 frames of latency.
Since the display panel is in the end the one that's driving the timing really minimizing latency would require lots of syncing so that the whole camera, encoder, transmitter and receiver work just right so the data arrives at the point where it is to be sent to the LCD as close as possible to the moment where it is to be sent to the display panel, with minimal buffering with only small FIFOs containing a fraction of a frame between each component instead of one or multiple frames. And some fast, logic-driven (hence FPGA again) that is capable of "filling in" the data to be sent to the display when a packet is missing at a small multiple of the pixel clock which is typically 25ns on a 800x480 panel.
That's what makes it hard to use off the shelf stuff. Almost all of it just puts buffers between each step so as not to have to bother with that, and it's why you get >100ms latency with most standard camera->computer->RF->computer->display chains.