If you upload demo videos to GitHub, you might have encountered the frustrating "This video is too big" message for files over 100MB. I've developed a solution: GithubVideoCompressor. This app lets you quickly compress and upload videos up to 350MB directly to GitHub PRs.
Here's what it offers:
Local Compression: Ensures your videos are processed on your MacOS with M-series chips, keeping your data private and secure.
Chrome Extension: This extension streamlines the entire process. Drop your video into the PR, and the extension handles the rest.
Resource Efficient: The app runs only when needed, preserving your system's resources.
Installation Steps:
If something doesn't work, please post about your problem in a reply. Thank you.
1. Unzip the folder you downloaded.
2. Transfer "GithubVideoCompressor.app" into your Applications folder. Right-click "GithubVideoCompressor.app" and press "Open." A warning message will pop up, click "Open". It may take a few attempts to open it. Just keep trying. It should eventually work. The app does take 3 seconds to boot the UI.
3. When the app opens, follow the three installation steps in the app.
4. Once installed, completely close the application. The compression cannot work if the app is running in the background.
Requirements
* The application works on MacOS with M-series chips
* The extension currently is only built for the Chrome browser.
Disclaimer: This is a public Beta, un-sandboxed application. If you are uncomfortable installing the application, that is okay. This is the first public release.
Interesting project. I'm a bit confused as to why this needs an app to be installed. Since ffmpeg compiles to WASM, it seems like the whole process could be handled in the browser extension. Unless I'm missing something.
We are on the same wavelength chris_pie. ch_sm is correct, it is a performance issue.
My first iteration of this was a chrome extension with ffmpeg.wasm, but there were multiple problems.
1. ffmpeg-wasm uses web-workers to attempt to parallelize the requests, but github has content security policies preventing the creation of web-workers from a chrome extension.
2. We can use the ffmpeg single core version, but the speed ends up being quite slow. I'm not 100% sure why but my best guess is because ffmpeg.wasm doesn't have access or take advantage of the computer's graphics card. The chrome extension background service worker is also only single threaded.
The speed difference can be significant. i.e. On my M2 macbook pro I was getting 14 fps compression speed, compared to a 260fps compression speed using native ffmpeg.
This will vary, but I'd say around 5x to 15x improvement, similar to what ch_sm said.
The ffmpeg configuration I use is:
ffmpeg -i inputPath -an -c:v libx264 -crf 28 -preset ultrafast output.mp4
Feel free to test it out. If you want to test ffmpeg.wasm on the browser with web-workers, I have a work in progress demo page. The site is not updated yet, but at the bottom on the site you can upload a video and test the FPS of the ffmpeg.wasm on your machine. You will notice small <30MB videos get higher FPS than larger videos.
The speed of the compression is important, because I wanted the whole compression + upload to be faster or take just as long as uploading the actual file. This does depend on the computer resources and internet speeds.
By using the native ffmpeg binary, we get the fastest speed possible. I tried a bunch of ffmpeg configurations, this was the fastest one I found that works consistently. Let me know if you anyone knows a faster one.
I can’t speak for the author, but in my experience, ffmpeg-wasm really is a lot slower than native ffmpeg at the moment. As in 10x slower, in my informal testing, and that really makes a difference.
Second, could you explain some use case? GitHub has these limits for a reason, and there's probably better ways to host a 350MB video if you need it to be played on GitHub.
Third, if I understand right the whole thing looks quite complex when you could just give someone a simple guide on what ffmpeg invocation needs to be done.
1. Thanks for the info, this is my first time posting on hacker news.
2. BossingAround explains it fairly well. It is really about breaking out of Github. When you only want to quickly upload a video, and it break because of 7 extra MB, thats annoying. If you were to use ffmpeg, manually you need to do a few things.
First, you need to know where the video you just recorded is located which may takes you 10 seconds of brain power.
Second, you need to grab the script to compress the video from your notes, or use a alias/macro. (1-5 seconds)
Third you need to find the output video, then drag it back into Github. About (3-10) seconds.
This does not include the actual compressing time.
While this app you install once, and it should just work. When you drop a video into the Github comment field or description box, it will start compressing, then upload like normal. All while the developer can edit the text field. There is little break of the dev's flow.
If you care about maintaining the full 350MB, you can for sure post the video somewhere else, but that takes time, breaks dev flow, and is often not free to host 350MB files. In this use-case the important part is not to maintain the video quality, but that I can still understand and read the text/context in the video.
Also, another use-case for this is to keep these video's off external services. To keep the attack surface area down. The importance of this depends on your own company.
Third. The code is stupidly complex for such a simple thing (I definitely asked myself why am I building this over 20 times), but the actual use and installation of the app is super simple. Installation should take under 10 to 20 minutes. Most of the time is from installing ffmpeg. I tried really hard to make installation as easy as possible.
Once installed, app should just work. You should never need to think about anything. Install once and forget.
The use case is pretty much the 3rd sentence in the link:
> It is helpful if you accidentally record more than 100MB (the github limit) for a demo video you wish to put in a Github PR.
In other words, you have a video, you want to attach it to the PR, it's 105MB. Now your option is to put it on YT and share a link, or use this tool and be able to simply drag/drop it to the PR.
In the demo, the 118MB file is compressed to something like 18MB, which is quite impressive, and could also help people who have slow upload speeds.
It is a small niche use-case, but something I personally run into more often than not.
Other alternatives is use ffmpeg on your own, or use one of the thousand video tools on the market to compress the video. This is what I did in the past, but it made me open an external tool, then compress, then re-upload. It was an annoying 20-30 seconds of my time.
This keeps devs in the Github PR flow without thinking too much, which I find quite nice. I personally have been using this for 2ish months now since version 0.0.1. It is always a pleasant surprise when it works.
I often to this manually, using Handbrake before uploading screen recordings.
Screen recording software trade performance for file size, so reencoding it afterwards can result in much smaller file sizes. I've personally had recordings I ~100MB reencode to ~10MB.
Here's what it offers:
Local Compression: Ensures your videos are processed on your MacOS with M-series chips, keeping your data private and secure. Chrome Extension: This extension streamlines the entire process. Drop your video into the PR, and the extension handles the rest. Resource Efficient: The app runs only when needed, preserving your system's resources.
Installation Steps:
If something doesn't work, please post about your problem in a reply. Thank you.
1. Unzip the folder you downloaded. 2. Transfer "GithubVideoCompressor.app" into your Applications folder. Right-click "GithubVideoCompressor.app" and press "Open." A warning message will pop up, click "Open". It may take a few attempts to open it. Just keep trying. It should eventually work. The app does take 3 seconds to boot the UI. 3. When the app opens, follow the three installation steps in the app. 4. Once installed, completely close the application. The compression cannot work if the app is running in the background.
Requirements * The application works on MacOS with M-series chips * The extension currently is only built for the Chrome browser.
Disclaimer: This is a public Beta, un-sandboxed application. If you are uncomfortable installing the application, that is okay. This is the first public release.
My first iteration of this was a chrome extension with ffmpeg.wasm, but there were multiple problems.
1. ffmpeg-wasm uses web-workers to attempt to parallelize the requests, but github has content security policies preventing the creation of web-workers from a chrome extension.
2. We can use the ffmpeg single core version, but the speed ends up being quite slow. I'm not 100% sure why but my best guess is because ffmpeg.wasm doesn't have access or take advantage of the computer's graphics card. The chrome extension background service worker is also only single threaded.
3. I did build a custom ffmpeg.wasm using Jerome Wu's blob as a guide to see if there was anyway to get the compression speed faster https://itnext.io/build-ffmpeg-webassembly-version-ffmpeg-js.... It worked, but was not faster.
The speed difference can be significant. i.e. On my M2 macbook pro I was getting 14 fps compression speed, compared to a 260fps compression speed using native ffmpeg.
This will vary, but I'd say around 5x to 15x improvement, similar to what ch_sm said.
The ffmpeg configuration I use is: ffmpeg -i inputPath -an -c:v libx264 -crf 28 -preset ultrafast output.mp4
Feel free to test it out. If you want to test ffmpeg.wasm on the browser with web-workers, I have a work in progress demo page. The site is not updated yet, but at the bottom on the site you can upload a video and test the FPS of the ffmpeg.wasm on your machine. You will notice small <30MB videos get higher FPS than larger videos.
https://github-video-compressor.vercel.app/
The speed of the compression is important, because I wanted the whole compression + upload to be faster or take just as long as uploading the actual file. This does depend on the computer resources and internet speeds.
By using the native ffmpeg binary, we get the fastest speed possible. I tried a bunch of ffmpeg configurations, this was the fastest one I found that works consistently. Let me know if you anyone knows a faster one.
Second, could you explain some use case? GitHub has these limits for a reason, and there's probably better ways to host a 350MB video if you need it to be played on GitHub.
Third, if I understand right the whole thing looks quite complex when you could just give someone a simple guide on what ffmpeg invocation needs to be done.
2. BossingAround explains it fairly well. It is really about breaking out of Github. When you only want to quickly upload a video, and it break because of 7 extra MB, thats annoying. If you were to use ffmpeg, manually you need to do a few things.
First, you need to know where the video you just recorded is located which may takes you 10 seconds of brain power.
Second, you need to grab the script to compress the video from your notes, or use a alias/macro. (1-5 seconds)
Third you need to find the output video, then drag it back into Github. About (3-10) seconds.
This does not include the actual compressing time.
While this app you install once, and it should just work. When you drop a video into the Github comment field or description box, it will start compressing, then upload like normal. All while the developer can edit the text field. There is little break of the dev's flow.
If you care about maintaining the full 350MB, you can for sure post the video somewhere else, but that takes time, breaks dev flow, and is often not free to host 350MB files. In this use-case the important part is not to maintain the video quality, but that I can still understand and read the text/context in the video.
Also, another use-case for this is to keep these video's off external services. To keep the attack surface area down. The importance of this depends on your own company.
Third. The code is stupidly complex for such a simple thing (I definitely asked myself why am I building this over 20 times), but the actual use and installation of the app is super simple. Installation should take under 10 to 20 minutes. Most of the time is from installing ffmpeg. I tried really hard to make installation as easy as possible.
Once installed, app should just work. You should never need to think about anything. Install once and forget.
> It is helpful if you accidentally record more than 100MB (the github limit) for a demo video you wish to put in a Github PR.
In other words, you have a video, you want to attach it to the PR, it's 105MB. Now your option is to put it on YT and share a link, or use this tool and be able to simply drag/drop it to the PR.
In the demo, the 118MB file is compressed to something like 18MB, which is quite impressive, and could also help people who have slow upload speeds.
It is a small niche use-case, but something I personally run into more often than not.
Other alternatives is use ffmpeg on your own, or use one of the thousand video tools on the market to compress the video. This is what I did in the past, but it made me open an external tool, then compress, then re-upload. It was an annoying 20-30 seconds of my time.
This keeps devs in the Github PR flow without thinking too much, which I find quite nice. I personally have been using this for 2ish months now since version 0.0.1. It is always a pleasant surprise when it works.
Screen recording software trade performance for file size, so reencoding it afterwards can result in much smaller file sizes. I've personally had recordings I ~100MB reencode to ~10MB.
Tested it out, seems to be working well so far. Nice work!
I've been testing it out and works wonders.
It's pretty nice when I do forget about size.