I've said that by using CouchDB, Novacut gets real-time collaborative editing "for free". I've often gotten flack for saying this, but almost by definition CouchDB does do a real-time sync between multiple nodes... that's just how CouchDB replication works.
The thing we don't get "for free" is that the Novacut components have to be carefully designed to be network-transparent. We want both the UI and render server to respond the same whether a change was made by the local user or a remote user.
So even when using Novacut non-collaboratively on a single computer, we relay signals through CouchDB like this:
![]()
To be network transparent, the UI and render server can't talk to each other directly, so they emit signals by changing docs in CouchDB, and they receive signals by listening to the CouchDB changes feed.
The next thing I get flack for (hehe) is that this will be too slow (which by the way is a totally reasonable thing to give me flack for... if the user experience sucks, who cares what other cool properties it has).
So we want to know the latency between when a change is made in CouchDB, and when that change is received through the changes feed. And then we multiply this by 2 as in the worst case scenario, we need to make the trip twice, from UI to render server, and then from render server back to UI.
Now before I give you numbers, I want to point out that in terms of user experience, you never need anything faster than 16ms. LCD displays pretty much all refresh at 60Hz, and 1/60 is 0.01666... aka about 16ms between one frame and the next refresh. So in terms of user experience, there is no benefit to updating the UI in less than 16ms because they'll still be looking at the same image anyway.
I finally put together a proper benchmark to measure this latency. On my workstation I get a max latency of about 6ms, and on my laptop a max of about 7ms, both of which keep us under the 16ms budget for the round trip (although barely).
Granted, this doesn't give the render sever time to actually do much and stay under this budget, but that's okay. Staying under 16ms is what's needed to make an ongoing animation appear perfectly smooth. There is more wiggle room for acceptable latency between clicking the mouse and seeing a change, and in video editing, no existing software can do everything instantly anyway.
Point is, 16ms for the worst case round trip makes this architecture totally feasible. I imagine CouchDB hasn't really been optimized with this use case in mind, so there is probably some low hanging fruit where this could be improved (even config changes). And more importantly, communication with the render server is always asynchronous... so even if the render server takes a moment to catch up (it's video editing, gonna happen)... the UI will remain completely responsive at all times.
This crazy architecture was chosen as a way to make real-time collaborative editing feasible, but now I'd choose it even if we didn't need the collaborative bit. For one, it enforces a total separation between the UI and the backend, something always desirable but difficult to achieve unless they truly cannot talk to each other directly.
But the real crown jewel I think is giving UI designers sweeping design freedom yet the quickest turnaround possible: the "edit a file and click reload" workflow of web design. Yup, you can change the Novacut UI without even restarting the app (video, you want to click).
I really want to see more apps take advantage of this, so the key bits have been split out into a standalone Python3 library called UserWebKit. It's still a bit rough and there will no doubt be some API breakages over the next month, but if you're interested, head over to the Novacut Stable Releases PPA and give it a spin.
If you're on IRC, come chat with us in #novacut (freenode).![]()
The thing we don't get "for free" is that the Novacut components have to be carefully designed to be network-transparent. We want both the UI and render server to respond the same whether a change was made by the local user or a remote user.
So even when using Novacut non-collaboratively on a single computer, we relay signals through CouchDB like this:
To be network transparent, the UI and render server can't talk to each other directly, so they emit signals by changing docs in CouchDB, and they receive signals by listening to the CouchDB changes feed.
The next thing I get flack for (hehe) is that this will be too slow (which by the way is a totally reasonable thing to give me flack for... if the user experience sucks, who cares what other cool properties it has).
So we want to know the latency between when a change is made in CouchDB, and when that change is received through the changes feed. And then we multiply this by 2 as in the worst case scenario, we need to make the trip twice, from UI to render server, and then from render server back to UI.
Now before I give you numbers, I want to point out that in terms of user experience, you never need anything faster than 16ms. LCD displays pretty much all refresh at 60Hz, and 1/60 is 0.01666... aka about 16ms between one frame and the next refresh. So in terms of user experience, there is no benefit to updating the UI in less than 16ms because they'll still be looking at the same image anyway.
I finally put together a proper benchmark to measure this latency. On my workstation I get a max latency of about 6ms, and on my laptop a max of about 7ms, both of which keep us under the 16ms budget for the round trip (although barely).
Granted, this doesn't give the render sever time to actually do much and stay under this budget, but that's okay. Staying under 16ms is what's needed to make an ongoing animation appear perfectly smooth. There is more wiggle room for acceptable latency between clicking the mouse and seeing a change, and in video editing, no existing software can do everything instantly anyway.
Point is, 16ms for the worst case round trip makes this architecture totally feasible. I imagine CouchDB hasn't really been optimized with this use case in mind, so there is probably some low hanging fruit where this could be improved (even config changes). And more importantly, communication with the render server is always asynchronous... so even if the render server takes a moment to catch up (it's video editing, gonna happen)... the UI will remain completely responsive at all times.
Bonus Round
This crazy architecture was chosen as a way to make real-time collaborative editing feasible, but now I'd choose it even if we didn't need the collaborative bit. For one, it enforces a total separation between the UI and the backend, something always desirable but difficult to achieve unless they truly cannot talk to each other directly.
But the real crown jewel I think is giving UI designers sweeping design freedom yet the quickest turnaround possible: the "edit a file and click reload" workflow of web design. Yup, you can change the Novacut UI without even restarting the app (video, you want to click).
I really want to see more apps take advantage of this, so the key bits have been split out into a standalone Python3 library called UserWebKit. It's still a bit rough and there will no doubt be some API breakages over the next month, but if you're interested, head over to the Novacut Stable Releases PPA and give it a spin.
If you're on IRC, come chat with us in #novacut (freenode).
