Search for a command to run...
I'm an indie developer based out of my home, lol, and love to create awesome applications. People call me picky for adding extra attention to detail and over-doing stuff, while sometimes I feel like Jerry-Rigging everything I make
Yeah, it is possible! You just need to intercept the inputProps params on the network tab when you hit "Render". Then follow the instructions on Remotion's website and pass the inputProps there
I think this is the #1 tool for me. Now, I can easily create really really good mockups for my hackathon projects, products, and more!
Thanks buddy! Happy to hear that!
Thanks! Glad you like it 😃
Are there more details? Or a public URL we can check the project? Thank you.
Hey Eleftheria Batsou, I was just in the process of editing the article to be more descriptive. The intro video took a long time, hence the delay.
Thanks!
Rounak Singh Eleftheria Batsou
Mohit Yadav you are still committing to your GitHub repository 6 hours ago whereas the Hackathon ended on 1st July 12:30 pm (IST).
Rounak Singh I know. You could check the commit till 30th of June, the app was already fully complete.
The only things I changed after the date are either visual improvements like adding the play button on the homepage video, adding analytics, license, or changing the default text in some template, nothing functionality wise. You're free to only consider the repo that was available on the 30th. You won't find any noticeable difference. Just that the product is used by me very frequently, so I try to improve it a little, every time I notice something, even after the hackathon ends.
I did the same with Pckd (for the Netlify hackathon), and now it's one of the top open-source URL-shortener projects. I hope that won't be a problem now? 😃
First of all committing and pushing after 1st July in submitted repo is unfairrrr!!!! Second, the changes were nowhere near to small, it had 55 file changes with 5k+ additions after 1st July. If you wanted to make changes for the sake of using yourself, you could've done it in a local or private repo and not submit in the blog. I do not think others are fool who try to finish everything (from UI to code with all bugs fixed) before hackathon ends. Your app is interesting and useful, but man you lost my respect! Even I could have added a ton of features in my project but I'm doing so in a private repo. I believe everyone should wait till the results are announced before making any changes to their repository.
Rounak Singh I understand your concern. I've fully made sure to not change any noticeable functionality of the application.
Just that I wanted to track the clicks I was getting, so I added analytics. Some people reported some typos, so I changed some text. Just had a few complaints of errors not showing up if progress is struck, fixed that. Most of them because I went with JavaScript for this project, not TypeScript. You could even see the commit messages and have a look at the changes, they're mostly silly typos or updating mundane-stuff.
I believe I do not stand an unfair chance with making any of the changes, and besides, these commits contribute to less than 1% of the code (the 5k+ additions is git's problem that it does not differentiate renames with changes. Like if I change the name of the src file to source, it would show 99% lines added, 99% deleted. These changes show because I renamed a template from fancy presentation to angular presentation to make it sound more descriptive, and also renamed some SVG files). If you do not agree, you're free to go back to the commit on 30th June and report any noticeable changes you find you feel are unfair to submit after the deadline.
This does not change the fact that the project was full functional, completed and submitted even a few days before the deadline. As I said before, feel free to go back to any commit you feel makes a significant change in my project's marking. Git is a very transparent technology, and it's up to the judges to decide which codebase to consider. I do not agree with how altering less than a few typos and minor stuff could result in respect changes when the project is so huge 😃. Thanks!
Rounak Singh He actually booked a slot. The entire article was blank by the deadline.
Manage and sell your properties effortlessly!
Or at least, in theory | Story of how I built Pckd, the most tracking-intensive URL shortener
Increase your productivity by 10 folds! The most underrated extensions that you're unaware of
On this page
Have you ever wanted to upload a video presentation/teaser of your app online but it looks too plain. Maybe you just wanted to add a gradient or throw in some background music. The only way is to install expensive or resource-heavy overkill video editors, or rely on some sort of online editor that asks you for a premium plan to export without a watermark.
Well, no more!
Mockoops is an online mockup-tool which allows you to just drag-drop your screen recordings, choose a template, throw in some background music, all previewing everything right in your browser.
Here's an introductory video
Here's how you'll create a video from scratch.
Here's what Mockoops calls home:
🌐 Website: https://mockoops.mohitya.dev
🐱 Code: https://github.com/Just-Moh-it/Mockoops
Mockoops comes with a bunch of templates right out of the box! They are very responsive, customisable and diversified for each of your motion-graphics video need. Some of them are here:
This template is idea for long-form content to make it more appealing (and possibly less boring too!). Here's a quick Showdown
This one is great for quick teasers that start out by build anticipation in the begenning, revealing only certain part of the input video at first, and slowly reveal the entire thing.
Here's me, using it for Pckd's reveal
This one is for the more lo-fi people out there. This template lets you present your video on a moving MacBook screen on a beautiful workstation background. This could be used with non-screen recorded stuff as well!
This one is for short announcements or reveals. Most suitably when you just have one screen for an app and you want to tease the coming soon status!
Or it could even be used for things like the release of a new version of a product. The possibility with this one are endless
This one is well suited for use-cases where you need to present some text before a video, while not having to setup any fancy stuff
With this, the templates end for now. I have a lot in mind as to what to add next. But considering the tight schedule for this hackathon, I'll have to keep that for later.
Mockoops comes packed with awesome features you're gonna love
This portion is explained in later sections
Preview videos right in the browser, then export with a single click
Unlike any other video ediors like After Effects, or Jitter, Mockoops has responsive video templates so that you could export videos with any dimension you'd want.
Mockoops even works in offline environments (preview mode).
Since the app was created with user-friendliness in mind, keyboard shortcuts were on the priority when assigning actions to buttons. Here's how power-users could utilize shortcuts to render video without touching their mouse.
Mockoops uses Remotion for the rendering.
Here's what remotion is in 100 seconds
tl;dr It's basically a way to create videos programatically with React. It allows developers to create responsive and absolutely positioned
I used my go-to tech stack for this one. Since Linode could run any technology you'd want, you're free to choose. I went with:
The app idea The app idea actually came out of the need for creating/building presentable screen-recordings, for announcing my new projects on twitter.
Apps that do the beautifying and presentation part exist for Images (like pika.style), but none for videos. So, it was obvious I had to fill the void.
As every other developer who tries to design, I'm not too good with designing things on my own. I usually browse websites like Dribbble to get inspiration for User Interfaces.
I also usually have the plan in mind on how the app flow would be like. This makes the process much more simpler, and I could concentrate on one part at a time.
(Detailed description... soon)
Care has been heavily focused on in this project. Unlike most hackathon submissions, I plan to use it very frequently, and so, the code was written with maintainability in mind.
(Detailed Description coming soon)
The GitHub commit messages are a joy to read as well, in case you're wondering
Linode played a major role in most aspects of the application. Here's how.
Usually, video processing happens through an API on the same server as the backend. In the traditional way, it would apply to Linode, by having a virtual machine, which runs the NextJS server through an Nginx proxy, with API endpoints to render and get progress.
However, this approach would be highly inefficient and non-scalable in case 50 people render at the same time. Though the server would be able to serve the frontend, the backend would not be able to handle this rendering workload.
This is where serverless comes into play. By leveraging the power of serverless, Mockoops could have a thousand concurrent users, all rendering at the same time while not having to compromise on any part of the application performance.
This is especially useful for maintaining the super-fast response times of Mockoops, while not having to deplete the monthly transfer costs. This also makes Mockoops compatible with the micro-services architecture, where the frontend is one service, the backend another, and the rendering engine to complete the architecture.
With Linode, I was able to get Mockoops from development to production within minutes. I even setup an Nginx Proxy Pass and added an SSL certificate. Though it's not as easy as something like vercel, etc. and there's a learning curve, once you get the hang of linux commands, it's much better since you have all the control you could have over deployments.
Linode also allows for easy domain management for free (until you have at least one VM). Unlike the registrar's nameservers, updates propagated through the DNS instantly as soon as they were edited from the console.
I probably don't need this very often, but with this project, it was crucial. Since the rendering infrastructure was open to anyone, and engineering a protection system to prevent repetetive renders was not possible, the application was vulnerable to DDoS exploits.
I know this is thinking too far, but one of my friends actually got DDoS'ed very recently on a hackathon submission. His project was down for a very long time and his hosting bills probably touched the clouds.
This is where Linode's built-in DDoS protection comes into play. It automatically notifies when repetitive queries are being sent to the same service and if it detects some level of exploitation. Though it's not perfect, I could enjoy peace of mind at no extra cost.
Learning is the main driving factor behind hackathons! Mockoops has been lesser of a web application and more of a teacher to me. To sum it here, here's what I learned:
Through a limited pre-alpha testing I did with some people for this app, I found out that most just pressed render on the video templates without changing any parameter. This meant that most of the renders were exactly the same.
This was a huge opportunity to save cloud costs. I just needed a way to identify each render uniquely. This was done through non-cryptographic hashing.
If you don't know already, a hashing function is a function which takes in an input of arbitrary length, and produces a fixed-size output based on the input. Even when the input is slightly changed, the resulatant output string is totally different. Hashing is used mainly for securing password storage, along with salting, etc.
Hashing was particularly useful for my use-case, since the input props to the video could be given as the input to a hashing function (SHA-256 in this case), and it would produce a hash which would act like an ID for the video. If the hash of two video requests is same, it means the same is exact video is being requested. Therefore, it is very efficient to serve the already-rendered video.
Using this method, I was able to decrease the render requests by a large factor, while also making the user interface better. In hindsight, it was well worth the 3 days setting up rendering infrastructure took me.
I was always fascinated by serverless and the JAM stack, but this project took it to another level. Using Remotion Lambda, I was able to deploy pre-built functions across different regions around the globe, and scale on demand.
With serverless functions, serverless sites was another thing I never though of, which came out to be a crucial requirement to access the serverless functions through an API. It taught me about scaling massively, the cold-start problem, caching, cache-invalidation, and a lot more.
Setting up the rendering process was a nightmare. Since the videos are rendered on a serverless architecture, the initial setup was much more complicated that normal server renders. Also, Mockoops needed to show a progress bar for each render for a better User Experience.
I first though about client side rendering. However, it was not feasible since browser has to process the video in real time and if there are some interruptions, they are recorded as well, and the final video is not as smooth. It also takes twice the length of video to render, which is not ideal for a good user experience.
Therefore, I had to resort to client side rendering, as the remotion community had too. This meant hosting the infrastructure to render and store videos, which in itself was a challenge, but Linode user-friendliness made the process less painful and more of a joy.
It also taught me about FFMpeg and how it works behind the scenes. Remotion Lambda opens up the video in a Chromium browser controlled using puppeteer. It goes through each frame and dleays the renders until a video/image has loaded. It then takes a screenshot of the window.
This happens for all frames in the video. Finally, they are attached together using FFMpeg, which is an awesome tool I didn't know of before.
I learned how to convert a video from mp4 to gif without having to rely on online solutions
This project was supposed to be an easy build, but oh boy, what an understatement!
Mockoops was no less that a roller-coaster. Though it taught me some valuable lessons.
It was hard to make remotion compatible with the latest versions of NextJS, since react 18 made significant changes in the browser rendering process and also changed some things from the ground-up. Though remotion had been tested against React 18, I'm afraid not so with NextJS 12.
So, every now and then I was getting ambiguous error messages that I had no idea how to fix, and the solutions online seemed to make no difference. After much struggle and avoiding to downgrade my React and NextJS versions, I had to finally downgrade to React 17 and NextJS 11. It took me 2 days of debugging and finally having enough to make the switch.
Since downgrading, I haven't faced any silly error message and everything worked exactly like I wanted to.
Lesson learnt: Never hesitate to downgrade your tech stack versions if it is hampering too much with progress. The change would probably be very in-significant (unless ofcourse new features aren't a business requirement).
Want to tinker with Mockoops? Want to add a template? To setup your own instance of Mockoops, read the docs over on the GitHub repo
Mockoops could be made better by:
This is one of the longest blog posts I've written, since I wanted to summarize the entire process.
Mockoops has been a journey of creating a vision to reality. Though there were some bumps and even speed-breakers, I finally managed to get it through the tunne... Well the analogy went too literal. 😅
This was one of my first experiences launching a product (on product hunt as well, soon), and it sure was hell of a fun one!
If you've reached this far, I'm grateful that you read the article. I'm excited for the results and the prices (since I'm saving up for college). Till then, later!
