Inspired by Photopea (a free Photoshop clone), I created this web-based motion design & video editor as an alternative to After Effects, to fill empty void.
It's free, without signup, without cloud uploads (your files stay on your machine), and your projects are not used for AI models training.
A 30fps limit is surprising
23.976 as an fps does not seem to be dealt with gracefully
Clicking report bug should take me to a bug report form with info
Interacting with "rectangle" is surprising because the corners aren't draggable. Probably should default to full size
I should be able to wind input fields by clicking and dragging on them, such as for rotation
When I drag keys around in the dope sheet, and let go with momentum, they appear to keep moving and "settle" in a sort of random place. They should not do that
I see that this momentum behavior is also in the play head in the timeline. It really should not do that.
Putting in a value in the dope sheet should be enabled, and it should automatically set a key
I liked the visualizations of the easing, but it should probably be communicated with the keyframe's icon shape in the dope sheet like it does in AE.
It is difficult to move a key to the beginning of the timeline.
Architecturally, the preview rendering probably has to work the way it does in After Effects. Guaranteeing a real time visualization is pretty important.
The big picture feedback is that often there is an alignment between “I have a lot of ideas for unique UX I want to implement” and “I want to wake up this morning and work on this all day.” IMO just copy AE’s UX affordances first if your goal is to make something you want other people to use. Blender spent a decade in the doldrums until it found an audience the moment they relented and copied Maya and Unity’s superior, conventional controls.
@clementpiki I second this advice and strongly suggest to document it as a guideline for your project as soon as possible. Surf on the shoulders of AE's UI giants!
Otherwise a small but vocal number of devs users who implicitly love FOSS software will end up rationalizing all the little UI quirks as features. Worse, their lack of expertise in UI design will be proportional to their level of energy and post length on all your communication channels. It's the epitome of bike-shedding. But if you just standardize on "whatever AE does" nobody will spend a moment advocating for putting quirks into the UI. (Plus they'll be very forgiving about quirks since it's obvious that getting the UI to work exactly like a proprietary piece of software is a very difficult problem.)
It's like walking into a car dealership and they tell you their car is free, and you ask where the seats are, and they say "why, on the ceiling, of course. We didn't want to copy all those other car companies."
You pop open the hood and there's no engine. "Where is the engine?" "On the roof!"
"Where is the gas tank?" "It's that plastic bag you keep on your lap."
The visual look can be protected, some novel or distinctive features can be patented or trademarked (like Amazon patented one click purchases??), but the core functionality is up for grabs
The big Oracle / Google lawsuit a few years back is a good example. Google rebuilt the Java compiler to avoid paying licencing fees (?), and argued that because they did it from the API specs, without referring to the existing code, it was aboveboard. The functionality is not copyrightable, just the specific implementation.
If you can't duplicate it, I can send you a short screen recording (I would just upload, but where do you upload <1MB binary files nowadays that isn't an ad-filled mess?)
it has a web player built in as well.
To me, it's "author / project lead has no background in the industry or even basic knowledge of video."
Isn't this no longer an issue thanks to SharedArrayBuffer?
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
I believe the ONNX Runtime uses this for multithreading on the web, see https://github.com/nagadomi/nunif/issues/34
Web Codecs can take a compressed media packet and get you the decoded image or audio buffer it corresponds to. Conversely it can take audio or images with timestamps and get you a series of encoded media packets you can then containerize (we say mux) and get you e.g. an mp4 file.
I don't know if this project uses it, but there's ffmpeg.wasm [1].
Several years ago I built a prototype of a video renderer on nodejs (v0.8-ish). It's a silly thing to do, rendering video in javascript (especially a decade ago), but it worked well enough to prove that it could be done and a startup pivot was born - one that was eventually acquired by Vimeo.
While a colleague (and now friend) was working on porting my silly little renderer to C/C++ to try to get closer to real-time, I built out a UI to allow us to "templatize" dynamic video for our users. This made it possible for our designers to design the video experience for the videos that were dynamically generated for our users' content.
That UI very much resembled Flash. Since then I've always wanted to do what you've done here. Before acquisition, I was asking our designers to walk me through how they use After Effects, in the hopes of building our tools in that direction, but then Vimeo showed up and... not too long after I left to start a travel startup. I haven't revisited the video space since.
I love this. I _knew_ that it could be done - especially now that WASM is stable - and I'm excited to see someone has done it. And free, no less!
Edit: Thought it was open source - thanks for the correction. Also I was way off on the node version.
https://techcrunch.com/wp-content/uploads/2006/04/jumpcut.gi...
...sadly, acquired by Yahoo, and you know what happened next.
I can't find a lot of screenshots / video from the era, but the one above should give you a sense of it.
Based on the great response you've gotten so far, I'd suggest focusing on ways for the community to expand on what you've built with templates and plug-ins.
It will take significant resources, cash and teams to make this into a serious contender, and folks that have problems to solve will always be happy to pay decent dollars for great software.
What's needed now is a page where people can share the templates they've created.
So I spoofed the user-agent in a nightly build here on my Linux desktop workstation, then had to alias one method that we should have implemented years ago but only have with a `moz` prefix (`HTMLMediaElement.mozCaptureStream`). This is on us to fix.
Then it looks like a worker script is served with the `Content-Type` `text/html` instead of `application/javascript` or something like that. We also have a pref flip to bypass that check, so I did that, but this is on the dev to fix.
When you do this it works, I've loaded project demos containing videos, audio, various things composited on top, scrubbed the timeline aggressively in a debug build, moved things around in various bits of the interface and also in the rendering frame, etc., things seem to work as they should, perf is as I'd expect it to be (and again, I'm running it in a debug build with optimizations disabled for anything media related, enabled for other parts of the browser).
What's missing is `window.showSaveFilePicker` and file system related stuff. It's possible to use https://developer.mozilla.org/en-US/docs/Web/API/File_System... instead (that we ship, e.g. Photoshop on the Web uses it). We think that it's much less scary than giving access to the file system to a content process of a Web browser. Maybe because videos can sometimes be extremely big files, direct access to the FS could be of use there. Thankfully, we also ship extremely modern video encoders to make them tiny instead, but that's currently a limitation Firefox has, for better or worse.
Obviously the permissioning model needs to be thought out here. It could perhaps only be available to "PWA"s that have been "installed", only on https sites, and only once explicit permission has been given, etc.
But it's so cumbersome to have upload/download be the only way to sync files into a web app.
OPFS provides high-speed read and write for temporary files and non-exported files; again this is what Photoshop uses. There is a 10GB limit per domain currently. I'm not sure this particular app actually needs that, though
> Why no Firefox support Firefox is my daily web browser. As a web developper, I always make sure my work is comptatible with all major browsers. But you can guess a web based video editor is a complex task to achieve, and Pikimov uses several key features that only exist in Chrome, Edge, and maybe Opera, and maybe, maybe, Brave. That's why Pikimov cannot currently work on Firefox (as of today: v127), there's nothing I can do to fix this, it is just not possible. For the curious ones, here are some of the web API Pikimov requires, but are missing from Firefox: - audio data - window showsavefilepicker - videoencoder Note: There is no Safari support due to similar obstacles.
- https://github.com/mozilla/gecko-dev/blob/af09c55c0e6253ba8f...
- https://github.com/mozilla/gecko-dev/blob/af09c55c0e6253ba8f...
I use Firefox for all my browsing, but do web app development with and for Chromium. I'd gladly do it for Firefox, but people, especially users, suck and sometimes one has to accept this.
Glad to see no time is wasted for Safari/iOS support. It's a huge waste of time and people using Apple devices are to blame.
It is the right of developers to say "I don't want to support your browser" and you should respect that decision even if you disagree with it.
As a reality check, see this ticket: https://bugzilla.mozilla.org/show_bug.cgi?id=390936
It took Firefox 17 years of back and forth with developers to add parity with an Internet Explorer feature that Chrome supported since version 1. This late in the game IE is already dead for good.
Not everybody has infinite time or infinite money to support Firefox, as an aside, you knew what you signed up for when you made Firefox your main browser.
So please, change the "clarify why you don't support Firefox" tone with "I want to make the site work with Firefox, how can I help you?". And good luck making the Firefox team change their mind when they decide not to support X feature, because it is also their right to do not implement the whole spectrum of features that Chrome supports.
I think they genuinely were interested to learn more about the deficiencies of Firefox.
I did - a better browser than Internet Explorer. Granted, that was 20 years ago.
It's not just AI.
I diligently disable Adblock on that website and have donated a few times in the past to support them.
I hope to see many more alternatives on the market, and lend my support to anyone building!
For speed, an editing app may also produce lower-res versions in memory for quick seeking and smooth playback, as a kind of quick preview. But that's easy to control how much memory you allocate for that, and even those previews can be stored or cached on disk.
Video editing is not especially memory-bound on modern machines. It's much more CPU/GPU-bound when it comes to applying effects, and IO-bound (including decoding-bound) when it comes to larger videos like 4K and 8K.
I.e. 1. Newer API such as directory access, which would let the app utilize something like swap as necessarily. And only ever loading the data it can currently handle from the filesystem (https://developer.mozilla.org/en-US/docs/Web/API/File_System...)
2. Input doesn't necessarily have to be RAW/8k. You get several h of 1080p AV1 video within 4gb.
I think it ultimately depends on how much effort the Devs wants to invest to support large video inputs. If none is invested, then your assumption would be true.
I was unable to find the source code, so I wasn't able to check for myself. We'll have to wait for the author to chime in, if they're willing.
2. I'm assuming video editing software works on a raw format in memory with access to individual frames? Just like Photoshop would need access to individual pixels from an importend JPEG, the actual canvas uses a lot more memory than the compressed input format.
What are your plans for further development? I guess for this complex project to evolve in order to meet the needs of the professional users it will require lots of work/team/resources/etc.
Do you plan to monetize it somehow in the future? or how are you going to sustain it?
Another free alternative to AE (targeted at more casual users) that comes to mind is CapCut... which is obviously a ByteDance product. And they already offer tons of features for free, so the competition could be tough...
Comparing a web-based software that runs on your own computer vs. installing a (say native) software and frequently updating, isn't it interesting that the former is faster to do? When using a web-based software to ru on your own machine, you are effectively, momentarily, installing it and are able to uninstall by clearing the cache.
Targeting Chrome targets all of the platforms, and the machines and platform is "fast enough" to do the job without having to dig deep into specific nature of the platforms.
It also leverages, I'm assuming, the deep knowledge the developer has of doing other things for the browser platform.
They probably could have targeted some other portable GUI toolkit, but this was more familiar. It may well be an even smoother experience than using other cross platform GUI toolkits, plus, of course, the platform is free.
Finally, distribution is familiar and likely easier, it's truly cross platform (no need to build executable on the individual platforms, even if its all from the same source base), etc.
No bundling, no signing, no app stores. Just a URL shared in a tweet and you're on your way. If it was OSS, it could be parked on a Github page for all eternity.
Overall, it's a really attractive platform for developers, just not yet fully embraced I think, as client based applications I mean.
You can load+interpret JavaScript files dynamically as the user accesses certain features.
But also, I would like to use motion graphics in an app where the software engineers don't have to re-implement each asset in code.
Are you planning on creating a company out of this? Are you going to monetize it?
1 - https://m.youtube.com/playlist?list=PL3pnEx5_eGm9BbCp2ZTj6LT...
Would you consider building in support for color spaces into the software? It looks like the working color space is linear sRGB, but it'd be nice to at least know, and also support other color spaces as well.
Frequently, when I'm rendering from blender, the raw renders will have out-of-gamut colors, which I'll then correct and bring back into sRGB when compositing.
Glad to see browser technology being put to use. Browser is by far the best API for desktop applications too, despite the very common ignorant complaints on HN.
Kudos!
It's cool, and free. But what happens when you get bored and take the site down ?
I know people hate on Electron (sometimes rightfully so), but this does seem like a nice use case, meet your users wherever they are, even offline!
As for when I need something native, Kdenlive is pretty nice: https://kdenlive.org/ (it's FOSS, they could probably also use a donation https://kdenlive.org/en/fund/)
Oh and DaVinci Resolve, even though effects aren't the main focus (it's a fully featured editing suite): https://www.blackmagicdesign.com/products/davinciresolve
This is even more important if the app uses some kind of proprietary project file format, since if the website goes down you won't even be able to recover your project (without heavy reverse engineering potentially).
Yeah other compositing tools exist but they lack the animation/mograph tools of AE, or animation tools exist but lack the scripting/filters/compositing.
Keep up the good work
https://natrongithub.github.io/
"Open Source Compositing Software For VFX and Motion Graphics."
...jk!
On a serious note, this is REALLY cool. Great job.
Tiny feedback, your console is extremely chatty. I get this is a beta, but it still might be worth disabling that logging for production deploys.
I hope to see this evolve into a commercial product I really think it fills a need and it seems to work incredibly well.
(really cool btw, super impressive)
Today this submission is climbing rapidly. Was the tool very different 20 days ago? I honestly don't know! But you never know how submissions will perform here. It feels pretty random, which makes sense, and also is part of the fun of HN.
I have no insight into HNs peak active times, but posting right before them greatly increases the chance of a post taking off (works on other platforms too).
My speculation is, more people check HN when first arriving at work to kick off the day, and that's why his post today is doing well vs the previous one.
One model I'd love to see is a web based front end, but all video processing happens in the backend.
Then ship the app as a combined front/backend, or just the front end that connects to a remote backend. That backend could be a server in a studio with beefed up specs, or offloaded to the cloud for solo animators working on complex projects.
Seeing a project like this give me hope that we could decouple what the app does, vs how to control the app.
But what I mean is clicking on the render button in your desktop app and have the work done remotely and everything solved automatically.
When I tested a full ray-traced FPS demo in the browser and never noticed that the render was done server side, that’s when I believed this is possible.
We could be working on high poly files with global illumination and whatnot in a Chromebook.
I'm surprised big companies like Apple, Adobe, or Autodesk haven't solved this already. I remember having a conversation with a friend about this exact topic back in 2016.
Though companies who want to see your data might not be so keen.
On my phone, but will try it out when I get home.
15 years from now, will this site still be up?
Will you be able to open your projects from today, then?
I think web only is a really compelling way to get someone to try a product, but I’d much rather install a tool like this. Unless you could host the site yourself, of course.
I believe blender can do this, for example.
Nothing web specific about it.
Except I have to have those servers to run it on. It's the basic premise of why cloud vs onPrem. I didn't think that really needed to be stipulated at this level on this particular forum.
That software then does not require servers to run on, since it supports local processing.
In this way it remains accessible in the future and scalable right now. (Assuming local processing would be slow enough to hurt the experience)
Honestly, I didn’t think this concept needed to be explained at this level either.
- if the tool is updated continuously for 15 years it’ll still be up
- if it’s not updated, it will be technically irrelevant anyway and you’ll have switched to another tool by then
Future support is overrated for tools, just use one now and worry about tomorrow later.
I also use older software quite often that has long since been updated, such as older versions of Audacity, Ableton, Adobe Premiere, etc. for various reasons such as: not wanting to spend money, avoiding spyware, ads (see: Windows 11), and other bloat which often IMO negatively outweighs the positivity of new features. There are a lot of other small utilities that I still use that are 10+ years old because they still work fine and I know how to use them blind-folded. There are also tools that haven't received updates in many years but still work great, why would I bother to look for something new that potentially will spy on me and not offer the same functionality?
But sometimes you have important old projects.
For example, my parents used photoshop elements to touch up all of my sister’s baby photos.
But my parents were not very technical and kept most of the photos as photoshop project files.
Idk if project files that old will open in newer versions of photoshop, but I don’t need to worry, bc I can always find a download of that old photoshop elements and open the projects in there.
It’s not as much about daily use as it is about planned (or inevitable) obsolescence.
Everything web based WILL become unusable or change drastically some day.
Other points that weren't raised - I want to be free to work in situations where I have poor or no internet e.g. when traveling.
Tying tools down to whether or not a website is available and you have reliable internet access is a huge step backwards in my opinion.
One day, potentially out of nowhere, web based tools can just vanish.
Imagine you were working on a film school senior project and poof your video editing tool was just gone!
Even if they gave a week’s notice, that wouldn’t be enough.
That can’t happen with something like Sony Vegas.
- I pledge to only make network connections to X, Y and Z
- I pledge to only make GET requests to http://example.com/foo/*
- I pledge not to use canvas, iFrames or storage APIs
This info wouldn't be immediately useful to most users, but it could massively help experienced users with trusting local utilities.
Doesn't solve any trust issue since data can be send as part of the URL, and the backend response can change at will.
* first requirement can already be done using Content-Security-Policy header
* haven't found a suitable header for the second requirement
* third requirement can be done with Permissions-Policy header
Not relying on a server makes this functionality available for downloaded sites. I'm a big fan of offering single file builds for web utilities, and the pledge should be part of that build instead of something the user supplies.
Having this as a runtime API would enable easier integration - say I'm developing a video editor that needs some WASM blobs. It might be a lot easier to load the blobs and pledge no further network access than having the URLs known on the server-side.
A bit fiddly for sure - but seems comprehensive enough.
Future behaviour may be different.
Also on the web code can change. Either the site owner or by a hacker. There is value in checking network requests if you need to but it isn't fool proof.
If you had done this, even spending 10 hours looking at network traffic, you wouldn't have been protected from this hack: https://www.theverge.com/2018/4/24/17275982/myetherwallet-ha...
That was a technically sophisticated hack, but there are simpler ones, like social engineering someone to take over their site.
Put putting hacks aside...
Say you have a site and it doesn't mention whether the data is sent to a server and you want to find out. Now let's say that site does a backup to server but only when localstorage has run out of space, but you don't know that.
When you test the site in the network tab, and you haven't run out of localstorage space then you will see no XHR and assume it's all good, it never sends to the server.
You then use the app for a few days, hit the localstorage limit and it sends stuff to the server without you knowing. And yeah you can keep the network tab open all the time if you have the discipline, but you only know once your data has been sent. It is too late.
If you care enough about whether it sends stuff to the server to look at a network tab, then you probably care enough to want to know for sure.
With the web as it is now there is only one way - trust the site and hope they do the right thing, and are secure. Or only put stuff on there you are happy to leak.
So, made up situation: if you are using this tool to edit and release a whistleblowing related video as a journalist. Maybe you shouldn't!
You probably instead want a local app, running on linux, on a machine that is disconnected from the network.
Reading a historic log that shows you have been pwned does not prevent you from being pwned. It's the wrong tool for the job.
It does.
> You can, in fact, use the network tab to monitor a page's ongoing network activity as originally suggested.
Did you forget that this comment chain was about leaking data to the server? Observing that you have leaked (note: past tense!) your data is not a recommended way to prevent leaking data.
Break the cycle.
That's an interesting question, but I think it's also equally difficult to prove for non-browser software.
With web applications doing the same is more difficult, because you need to pass some requests, and some requests need to pass while others could be smuggling data.
https://addons.mozilla.org/en-US/firefox/addon/work-offline-...
They're the same types who'll insist that DALL-E is just making collages of other artists' work, for example.
People looked at this and immediately assumed this was added to allow Adobe to train models with people's private work.
Adobe has now updated their TOS, but this was a breach of trust.
Either way, in the end, this potential AI threat is just another reason to not store stuff in the "cloud".
Funny. In my experience AFK it is the people who use AI that have zero idea what it is and think answers can be blindly trusted. The ones who don’t like it can enumerate the drawbacks clearly.
FWIW I'm on the pro-artist side and anti-the current state of things, and wish we could start over with a collaboration between technologists and artists rather than each side having nothing but sneering contempt for the other.
Personally I dislike being morally steamrollered on complex, nuanced topics.
People don't like having bad or unhelpful AI features crammed into products but seeing the growth of ChatGPT, Midjourney, Adobe Generative Fill, Udio and Luma people definitely do like AI that actually works.
"No crypto" labels in the last cycle made sense to me. Similar to "no ads", it points to the business model incentives and how the product is intended to evolve over time.
Conversely, "no ai" feels like a very fuzzy line around which editing features will be included (smart lasso tool? object tracking to frame shots? background / foreground selection?).
There's plenty of alternatives to google analytics though. This sort of basic breakdown could be done with goaccess (or an awk one-liner); plausible, matomo or simple analytics would be decent options that cover most reasonable requirements.
I have a suggestion which has always served me well: Ask. Or don’t even ask, users will tell you what they want anyway. Analytics will only give you skewed information, as you are unable to distinguish the popularity of a feature is due to its usefulness, its prominence, or a general lack of clarity.
Non visible parts of aproject tend to get neglected a lot more if you just ask your users What will get more people talking to you, a 10% speed up split among many small interactions, or a visual glitch that doesn't affect usability but it's front and center?
And analytics won’t tell you that, so I don’t see your point.
> Non visible parts of aproject tend to get neglected a lot more if you just ask your users
Do they? Perhaps if you keep relying on analytics, they do. In my experience, users will just tell you anyway. And some of them will be better at feedback than others. Treasure those.
Also, and this is another topic, why don’t you use periods in your sentences? Your comment was unnecessarily hard to parse.
A good example is time tracking, people are notoriously bad at this, ignoring non events that consume time and over assigning time to task that demand attention
On the other topic, no real reason. I just suck at prose; I'll take the comment in consideration to improve that. That comment in general is just poorly written all around, I'd love to edit it, but the time window has passed
It would be great if you could use a self-hosted analytics platform instead! :)
And I would strongly advise not to develop based on anonymous analytics, users might tell you different desires if you ask them and use completely different workflows if added. Optimizing for web analytis metrics has ruined many projects.
That's an important distinction to make especially for a browser based app. It's also a very low bar IMO, but one that many other companies aren't clearing anymore, like MS, Adobe, and others.
Very little can beat just clicking "get started" and dropping right into the tool.
I hope no UI designer or a quality template will ruin it.
https://www.theverge.com/2020/1/15/21067907/google-chrome-ap...
https://en.wikipedia.org/wiki/Google_Chrome_App
> Support for Chrome Apps in the Chrome Web Store was removed from Chrome in June 2022, except on ChromeOS where support has been extended until at least January 2025.
