I'd love to make it do what you need.
The app uses a custom renderer inspired by ReMotion, so while the app can output MP4s, I also have a player that is dynamic HTML/CSS animation powered by JS, hosted either on my site. I could make it a player that is hosted from anywhere, and I think I will do this for a free tier.
Theoretically, this setup can handle videos of arbitrary length, but practically speaking, I've only thoroughly tested around 10–15 minutes. I'd recommend caution with significantly longer recordings (like an hour) for now, as you might encounter rendering issues.
Might be worth calling that out either way.
I've built a 100% web-based screen recording tool aimed at product marketing managers, developers, or anyone wanting to showcase their work along with a talking head. Inspired by ScreenStudio, it allows you to effortlessly create polished recordings directly from your browser.
A couple of technical highlights I'm particularly proud of:
Initially, I used ReMotion but ran into limitations. I ended up building my own animation engine from scratch, closely inspired by ReMotion's capabilities but tailored specifically for my use-case.
Due to browser security constraints with getDisplayMedia(), I couldn't directly track cursor movements. To overcome this, I trained a custom YOLO (You-Only-Look-Once) model for cursor detection. This allowed me to implement smooth, mouse-following animations within recordings, bypassing the browser limitations entirely.
Happy to dive deeper into the tech if anyone's interested!
I really want a free version from commercial use tbh, not that cursorful is expensive
Here is the JS-based player: https://screenrecorder.me/projects/s3hx9YRgXNsrN1s/player
Here is a video that I rendered: https://screenrecorder.me/player/s3hx9YRgXNsrN1s
There are definitely artifacts, especially in the latter, but in practice the videos I've been creating have been working well. Also, it's primarily because the zoom is so high.
In practice, I usually set the zoom much lower and it doesn't have as much artifacting. Check out the homepage video
The MDN support table does not differentiate in this regard.
I'm super passionate about this though. Totally up my alley as a Dev and aspiring Growth Hacker, Product Marketing Manager.
The idea is to build a tool and use it to grow itself.
Also, anyone want to talk offline about anything at all, please contact me at john@screenrecorder.me
First we really need the Source code of this tool though if we really want this tool to stay for posterity!
"If I make something so great then people will still pay me even if I give it away for free!"
A tiny percentage of people might still pay for it, but the vast majority will not, and will complain loudly about any attempts to monetize.
People are a nightmare, I can already see someone leaking secrets with this.
Few things I would like to see:
- Ability to add images in the time line, think of intro/outro.
- Ability to add notes (text) on frames to explain something or highlight an area.
As some comments mentioned, running locally is a must, and I have no problem paying for it.
Good luck
Thanks in advance
What are your opinions on the best way for you to pay for it as an open source tool?
Take the feedback, do some improvements. I will use it even if you don't - love it :-)
If you are approaching this from a potential business perspective that will not be the major issue. As you can tell from the comments most people do want their screen recordings on a remote service, now matter the policies involved.
That leaves you with some options :
1) Encrypt the outgoing WebRTC stream before it leaves the client device/browser (e.g. through WebRTC Insertable Streams or similar), encoded with a client local key that only your customer knows/manages. This ensures any screen recordings stored on your end cannot be accessed in any way. They can then download the recordings as needed and decrypt on demand. Note that this still has the implication of you storing and transmitting massive amounts of data which is likely to become cost prohibitive as a service.
2) As above but do the decrypting for your customer on your end so they get to download playable media. This obviously introduces the security risk of your platform becoming temporarily able to 'see' the content.
3) Save your recording directly through MediaRecorder WebM or similar (has various browser compatibility challenges as standards materialize) and uses less obvious encodings (we're still living with the bullshit of H.264 requiring licensing).
android521•9h ago
johnwheeler•9h ago