I’m developing a video editing website and building the backend with Go. While most features are working, I’m running into a few technical challenges:
Video Processing with Go:
I’m using ffmpeg-go to handle video processing tasks like trimming, merging, and adding transitions. However, the processing time for larger videos is significantly higher than expected. Is there a way to optimize video processing with Go, or should I consider a different approach, such as running FFmpeg tasks in parallel?
Real-Time Video Previews:
I’d like to generate real-time video previews (e.g., after a user applies a filter or makes an edit). Is Go suitable for handling such tasks efficiently, or would I need to offload this to a specialized service? If Go can handle it, what libraries or patterns would you recommend?
Handling Large File Uploads:
Users often upload large video files (sometimes exceeding 2GB). I’m using a Go-based server with a multipart form handler, but uploads occasionally fail for larger files, especially on slower connections. What’s the best way to handle large file uploads in Go while ensuring reliability and performance?
WebSocket Integration for Progress Updates:
I’ve implemented WebSockets to notify users about the progress of their video processing tasks, but the updates are inconsistent. Sometimes the server stops sending progress updates mid-task. Is there a known issue with Go’s WebSocket libraries, or could this be a problem with my implementation?
Optimizing API for Frontend:
My frontend (built with React) frequently interacts with the Go backend to fetch video metadata and update edits. The API calls are increasing in latency as more users join the platform. How can I optimize my Go APIs to handle high traffic while maintaining fast response times?
I’d love to hear suggestions, best practices, or examples from anyone who has experience building video-heavy platforms with Go. Any help would be greatly appreciated!
Point 5 is basically what I am good at and it seems that there is something just not right. How many users does the website have? Even without optimisation your backend should be able to serve a lot of connections and users.
If it is “your personal webseite” there should not be this problem at all, go is just naturally already fast.
Also you have WebSockets integrated and still a lot of API calls. (There is too less info to judge this, but maybe thats something to think about)
Finally your github account has a different person and maybe people are not writing here; they think you are a bot
Using S3-compatible object storage for handling large file uploads sounds like a solid approach. I can see how delegating file storage to a service like S3 would reduce the load on my Go server and improve scalability.
I have a few follow-up questions regarding this approach:
Integration with ffmpeg-go: Once the videos are uploaded to S3, would you recommend downloading them to the backend server for processing, or is it better to process them directly on the storage service? If the latter, are there any specific tools or libraries to make FFmpeg work with S3 efficiently? Additionally, I’ve noticed video editors like CapCut perform advanced processing tasks efficiently—do you think a similar optimization approach could work for server-side video editing pipelines? For those interested in exploring advanced editing features like those in CapCut, you can click here to check out CapCut modded apk version.
gRPC for streaming: Could you clarify how gRPC could be utilized in this context? Would it be for streaming video data between the backend and S3, or for communicating progress updates to the frontend?
Metadata storage: When you say “store the path and metadata in an RDBMS,” do you have a preference for how to structure this? For instance, should I store file versions (e.g., original, processed, preview) in a single table with different paths, or use a more normalized structure?
Thanks again for your input! I’ll explore this direction further and see how it can optimize my platform.
Out of my competence, but it sounds that the web server should convert it before sending to the S3 server.
What I am going to do is a “micro service” (gRPC server almost like an API) that only handle the communication between the web server and S3 storage. Probably could handle converting and other processing before pass the file to the storage.
Not yet there, but I imagine that I should store metadata for fast searching in the RDBMS. And the search criterias may differ from case to case.
I have used both of them. They are good integrated libraries. If you use static library compilation, the running environment does not need ffmpeg related shared libraries.
There are also other tool libraries that use command line calls, but in my opinion, they are very bad.
For other questions, I think others have answered almost everything, so I will not add anything.
I re-read your question and I think I should answer it again:
1.ffmpeg-go, this question is the same as what I said before.
2. Video preview, this is the same as the first question, calling some library methods to process can achieve the purpose. As for the efficiency issue: ffmpeg library can use hardware acceleration, which depends on the video type and the operating environment, please understand this yourself (but pure software calculation will not be too bad, at least on my relatively low-power CPU combined with OpenGL, my GUI screen can still display 60 frames of decoded video.)
3. For large file uploads, in addition to having a reliable storage backend, you also need to add a retransmission mechanism to the frontend and backend to perform breakpoint transmission when the transmission fails. This is a similar logic to your download.
4.websocket? If it is just to update the progress, I decide that ws is a bit heavy (if you don’t have the need for two-way communication or numerous and complex APIs, then don’t use ws, it will only increase your maintenance costs); ws library, as far as I know, there are no obvious defects in ordinary use, but it does not rule out that you have encountered a bug.
5. It seems that you just didn’t schedule the processing logic well. This is a complicated subject. I can’t point out the specific problem before seeing the complete code. But there are some common concepts. The simplest optimization is to adjust the processing logic, reduce mutual exclusion, etc.
