I previously shared my frame extraction tool (videotojpg.com) here about a month ago. The feedback was great, but it taught me that purely WASM-based solutions often hit a performance wall with larger files.
So for VideoCompressors.com, I wanted to see how close we could get to "native performance" in a browser.
The Architecture (Dual-Engine):
1.The "Fast Lane" (WebCodecs + GPU): The app first attempts to use the WebCodecs API to access your device's hardware encoder.
The Challenge: WebCodecs only outputs raw encoded chunks. The hardest part was implementing the client-side muxing (remuxing these chunks back into a valid MP4 container) without breaking synchronization.
The Result: When active, it's ~10x faster than WASM and keeps your laptop cool.
2.The "Safety Net" (FFmpeg WASM): Since WebCodecs support is still fragmented (looking at you, older Safari versions), I implemented a seamless fallback to FFmpeg (WASM). It detects if hardware encoding fails or if the format isn't supported, and switches engines automatically.
Privacy: Zero server uploads. I'm a strong believer that simple utilities shouldn't require cloud processing.
Request for Feedback: I'm currently tuning the bitrate control for the GPU engine. If you try it out, I'd love to hear if the quality-to-size ratio feels right compared to desktop tools like Handbrake!
That makes total sense. In a shell environment, breaking the flow for 10+ seconds would definitely be more painful than the memory overhead. The 'instant' feel is crucial for UX here. Thanks for the detailed explanation!
I built Video to JPG because extracting the perfect frame from a video usually requires scrubbing through timelines manually, which is tedious.
This tool runs entirely in the browser. It uses a hybrid approach: prioritizing the native Canvas API for performance, and falling back to FFmpeg (WASM) for formats that browsers don't natively support (like AVI or MOV). It also includes a blur detection feature to automatically select the sharpest images.
Key features:
Smart Selection: Automatically detects and filters out blurry frames.
100% Private: All processing happens client-side; no video is uploaded.
Format Support: Handles MP4, MOV, AVI, and other common formats.
I'd love to hear your feedback on the detection accuracy!
I dug into the repo – the 'self-healing' logic (automatically switching from CMD to PowerShell on failure) is genuinely clever. Much smarter than just dumping a stack trace.
A technical question on the v6 offline support (Phi-2): Does the CLI keep the model loaded in RAM in the background (daemon mode), or does it have to load the weights from disk every time an error occurs? I'm curious about the latency trade-off for that 'instant fix' feel.
I like the intent of keeping the flow state. Have you considered making this a CLI hook (e.g., a post-commit hook) rather than a web dashboard? I feel like I'd be even more likely to use it if I could just run git commit and have it prompt me in the terminal to confirm the tweet draft.
Makes sense. Just a heads-up on the hybrid approach: storing raw files in B2 while also ingesting to Stream means you're paying for storage twice.
Also, for the mobile app, definitely look into Direct Creator Uploads. You can generate a signed URL on your backend and let the phone upload straight to Cloudflare. It saves a ton of headache handling bandwidth on your own servers.
I've been using Cloudflare's ecosystem heavily for my video tools and can share some thoughts:
For your use case (40s clips, 10-50K plays/day), Cloudflare Stream's per-minute pricing model could be significantly cheaper than GCP, especially as you scale. Their ABR quality is quite good for 1080p/720p - I haven't noticed quality issues in practice.
One consideration: Cloudflare Stream has a 30s minimum charge per video, so for 40s clips you're paying for 60s. This might eat into the cost savings vs GCP.
Backblaze B2 + Cloudflare has free egress which is huge, but make sure you're using the Bandwidth Alliance properly to avoid surprise charges.
Have you considered keeping source files in B2 and only using Cloudflare Stream for delivery? That hybrid approach might give you more flexibility.
I previously shared my frame extraction tool (videotojpg.com) here about a month ago. The feedback was great, but it taught me that purely WASM-based solutions often hit a performance wall with larger files.
So for VideoCompressors.com, I wanted to see how close we could get to "native performance" in a browser.
The Architecture (Dual-Engine):
1.The "Fast Lane" (WebCodecs + GPU): The app first attempts to use the WebCodecs API to access your device's hardware encoder.
The Challenge: WebCodecs only outputs raw encoded chunks. The hardest part was implementing the client-side muxing (remuxing these chunks back into a valid MP4 container) without breaking synchronization.
The Result: When active, it's ~10x faster than WASM and keeps your laptop cool.
2.The "Safety Net" (FFmpeg WASM): Since WebCodecs support is still fragmented (looking at you, older Safari versions), I implemented a seamless fallback to FFmpeg (WASM). It detects if hardware encoding fails or if the format isn't supported, and switches engines automatically.
Privacy: Zero server uploads. I'm a strong believer that simple utilities shouldn't require cloud processing.
Request for Feedback: I'm currently tuning the bitrate control for the GPU engine. If you try it out, I'd love to hear if the quality-to-size ratio feels right compared to desktop tools like Handbrake!