It has been nearly two weeks since I last wrote a record. Who knows what I have experienced during this time? With a somewhat heavy heart, I document a recent pitfall I fell into. The heaviness comes from the fact that this pitfall was caused by a very, extremely basic mistake, and such a basic error cost me many days of time. I record it here as a form of progress 
.
The ESP32 Chip Used in This Article (Actually, It’s Not Related to This Article)
The Development Platform Chosen for This Article (Actually, It’s Also Not Related to This Article)
In this article, the ESP32-CAM module is used as the device for pushing video stream data, and the development software chosen for the program code is Arduino. The server-side software used for forwarding the video stream is SharpDevelop 5.0, a very lightweight and user-friendly C# development software.
Therefore, you will not see any code-related knowledge sharing in this article
Let’s get started! Falling into the pit…
In this article about pushing video streams from ESP32-CAM to the server for forwarding, we have implemented the ability to push video from the ESP32-CAM to the server via a WIFI network, and then the server forwards the video stream to mobile terminals for viewing. Our ultimate goal is to achieve a video-controlled car that is not limited by distance, so we cannot use WIFI; instead, we need to use a 4G SIM card. Thus, the pitfall begins…
I bought a 4G module and studied its communication capabilities. The final implementation method is that the ESP32-CAM sends video stream image data to the 4G module via serial, and the 4G module then sends the video stream image data to the server via the 4G network. If I hadn’t fallen into the pit, this should have been the end of it, but I fell into the pit.
Continuing…
On the second day of studying the 4G module: I was able to send the video stream image data (one image) obtained by the ESP32-CAM to the server.
On the third day of studying the 4G module: I was able to forward the video stream image data received by the server, and the client could view it. When the client saw the first image, the joy was indescribable 
On the fourth day: I tried to continuously send video stream images.
On the fifth day: I successfully sent images continuously, but the real struggle began at this moment…
On the sixth day: Why does it take about 6-9 seconds to send one image…?
On the seventh day: I struggled, struggled, and continued to struggle, step-by-step debugging the ESP32-CAM code, video stream forwarding server code, and serial communication code. Speaking of serial communication, it’s disheartening.
On the eighth day: Struggling………
Struggling………
One day at noon, I suddenly had a great realization.
What? Sending video stream via serial communication?
I immediately started calculating the transmission rate. At that time, I set the serial baud rate to 9600. That means transmitting 9600 bits per second. 1 byte = 8 bits. 1k = 1024 bytes.
9600➗8➗1024=1.17kb.
1.17 kbps, my goodness, what a concept! Why did I make such a basic mistake? No wonder it took 7-8 seconds to transmit a photo. That’s normal; an average image is about 8kb. Based on a frame rate of 25, at least 200kbps is needed to avoid stuttering.
Finally, I checked the parameters of the 4G module, and the maximum serial baud rate can be set to 921600.
921600➗8➗1024=112.5kb. The maximum can reach 112.5kbps, ultimately confirming that using serial communication with the 4G module cannot achieve smooth video stream transmission.
Well, I fell into this pit so badly; I record this to remember the lesson.
Finally……
I mean, I saw online that video-controlled cars are basically using a portable WIFI? After coming out of the pit, I decided to use the portable wifi hotspot solution. This solution has been basically debugged successfully, and I will share it with everyone after completion.