i love this but dont use emacs. i wish that existing tools were lighter weight at video trimming. Screenflow is the lightest i know of but fails badly at some video formats and sometimes OoMs. if it had a better architecture streaming bytes i feel like it might not have that problem.
Very cool tool, and always amazing what Emacs can do...
If this isn’t your _daily_ use case and you only need to edit video from time to time, just ask your preferred LLM to give you the FFmpeg commands to cut, speed up, mute, flip, add text, etc.
This has worked quite well for me with simple use cases, and well no need to learn Emacs.
This supports the meme of Emacs as an operating system. It would actually be nice if graphical integrations like that could be implemented as easily on our actual OSs.
This is impressive, but (and probably because I'm not the intended audience for this post) I don't get it, I kind of want to get it though. With "it" I mean making Emacs do X, where X is something far from editing text files. It always seems to me like playing Doom on a pregnancy test. Sure you can do it, sure it's impressive, but should you?
n.b. I'm a C# developer that has accepted my fate and use Visual Studio to earn a living, though I've made sure I know my tool, flaws and merits, better than most developers I've met/worked with. My first job as a programmer was writing C++ code in Emacs and can't remember anything negative about that experience (other than getting used to ctrl+x, ctrl+s for saving and, by reflex, doing the same in Excel, and losing a big part of the document that I had just selected to move, because Excel couldn't undo past last save).
Reading the (at the time I'm writing this) 13 comments on this post I see mentions of at least three lightweight programs that does this. What other than "the mountain is there" makes someone think Emacs would be the tool for this? As a Resolve user I know what tool I'd reach for even if using a multi GB, Hollywood grade, non linear editor, compositor and color grader for trimming a short video clip is about as ridiculously overpowered as using a sledge hammer to press a key (and I did exactly that just a few days ago).
Like I said, I'm most likely not "getting it", on multiple levels. Please educate me, why would I use Emacs for this or any of the page upon page of "strange" use cases you find if you search for "Emacs" here on HN. I know Emacs is a powerful editor but I can't for the life of me understand why I would use it to trim video clips.
If Emacs hardcodes the start and end times then a (single) benefit I can imagine is that QuickTime's UI (the typical go to) can be mildly frustrating if 100% of focus isn't on the screen. Somehow they manage to make moving a [] annoying. Indeed there are more options though.
This is pretty interesting; I had never thought of using Emacs as a video trimming thing, but why not? I've trimmed videos manually with FFmpeg and I've thought about building my own GUI to do it, so Emacs is as good a choice as any.
I don't really use Emacs but I love that people use it for everything; next step is a non-linear video editor.
Pretty neat. I use Emacs a lot, and also do quite a bit of video trimming. For people wondering "why Emacs?", here’s the use case: trimming video is mostly about writing down start/end times, sometimes with a note. That’s all text.
If you can turn that text directly into clips without switching to a separate video editor, it’s surprisingly efficient. Of course, this only makes sense if you already live in Emacs, then it reduces context switching, helps to keep the flow. If you don’t, it just looks odd. But it’s not about making a meme out of "doing everything in Emacs" - it is just a small tool that fits the workflow of people who are already in that environment.
Having been an Emacs user for 25+ years, I have a bunch of muscle memory.
So I created Emacs shortcuts for Davinci Resolve. (I create a lot of videos, and every time I've attempted to outsource editing, it has always been more work to review and give feedback than to just do it myself. I have a routine using the AI transcription features of Resolve that lets me edit video very fast. Editing a one-hour video might take 2-3 hours).
I'm also interested in hearing more about your process. I get bogged down going through my footage either comparing similar options, or trimming to the best action (best focus, least shake). I find the default Resolve keyboard shortcuts to be fast, and trim in the Edit mode (whatever #4 is called), but I'd love an AI augment that colour-coded clips based on which segments might be best (e.g., eyes/face in focus, or require least stabilisation, etc).
I have a Resolve Speed Editor panel but just found that to be far slower than the keyboard.
And the browser, which is functionally now a virtual machine with sandboxing that also happens to have native support for HTML rendering and a couple natively-interpreted languages.
I've been using emacs for light video editing too, but I took a different approach. Instead of having emacs deal with video directly, I use emacs as a JSON IPC client of mpv, over a unix socket, which handles the video. Over that IPC link I can control mpv playback (optional) and get timestamps/etc to add into an Edit Decision List (EDL) file.
28 comments
[ 3.6 ms ] story [ 54.1 ms ] threadany other light weight trimming people have?
If this isn’t your _daily_ use case and you only need to edit video from time to time, just ask your preferred LLM to give you the FFmpeg commands to cut, speed up, mute, flip, add text, etc. This has worked quite well for me with simple use cases, and well no need to learn Emacs.
n.b. I'm a C# developer that has accepted my fate and use Visual Studio to earn a living, though I've made sure I know my tool, flaws and merits, better than most developers I've met/worked with. My first job as a programmer was writing C++ code in Emacs and can't remember anything negative about that experience (other than getting used to ctrl+x, ctrl+s for saving and, by reflex, doing the same in Excel, and losing a big part of the document that I had just selected to move, because Excel couldn't undo past last save).
Reading the (at the time I'm writing this) 13 comments on this post I see mentions of at least three lightweight programs that does this. What other than "the mountain is there" makes someone think Emacs would be the tool for this? As a Resolve user I know what tool I'd reach for even if using a multi GB, Hollywood grade, non linear editor, compositor and color grader for trimming a short video clip is about as ridiculously overpowered as using a sledge hammer to press a key (and I did exactly that just a few days ago).
Like I said, I'm most likely not "getting it", on multiple levels. Please educate me, why would I use Emacs for this or any of the page upon page of "strange" use cases you find if you search for "Emacs" here on HN. I know Emacs is a powerful editor but I can't for the life of me understand why I would use it to trim video clips.
I don't really use Emacs but I love that people use it for everything; next step is a non-linear video editor.
If you can turn that text directly into clips without switching to a separate video editor, it’s surprisingly efficient. Of course, this only makes sense if you already live in Emacs, then it reduces context switching, helps to keep the flow. If you don’t, it just looks odd. But it’s not about making a meme out of "doing everything in Emacs" - it is just a small tool that fits the workflow of people who are already in that environment.
So I created Emacs shortcuts for Davinci Resolve. (I create a lot of videos, and every time I've attempted to outsource editing, it has always been more work to review and give feedback than to just do it myself. I have a routine using the AI transcription features of Resolve that lets me edit video very fast. Editing a one-hour video might take 2-3 hours).
I have a Resolve Speed Editor panel but just found that to be far slower than the keyboard.
1. keyboard driven
2. programmable
3. within an ecosystem they are already within (lightweight, cross-platform, etc).
Honorable mentions for AutoCAD, Blender, and Eclipse too.
:-)
Checked the source and it seems to make a lot of assumptions on the output format, codec and quality.