Hacker News Reader

Comment by sexyman48 | Hacker News Reader

[flagged]

It’s obvious that the author wrote the simplest code that could work, rather than spending extra time on complexities that might not be needed. They were quite pragmatic and achieved a useful and usable result. It’s commendable, so you shouldn’t sneer.

I'm not sure how you'd do it "properly" with libavcodec while still doing a regular Emacs plugin.

It's 300 lines and in pure Emacs lisp, it doesn't seem boneheaded to me.

> it doesn't seem boneheaded to me

It's not "boneheaded". Shit ain't stupid if thy shit works. This HN user is just a troll with condescending traits and arrogant tendencies, don't feed their ego.

I'm not sure how to libavcodec while still doing Emacs

I'm glad you see my point.

I just don't think it's that bad. Even if it spawns a process for each frame when you're scrubbing, it seems to run fast enough on my computer.

If you want to do a lot of advanced video editing then yeah use a real editor, but if you're just doing a quick trim it's really not a big deal to spin up a few dozen very-short-lived processes.

It’s probably be more efficient to convert the video to multiple frames in batches, and then buffer them. Spawning processes is pretty resource intensive.

I mean, "resource intensive"; that's technically true but the processes are pretty short-lived and only one spawns at a time as far as I can tell. It's definitely more overhead than an in-thread thing, but still not that much on modern computers.

I agree that it would be more efficient to do these things in batches but I really don't think its current state is that bad, at least for a V1.

The implementation actually uses a single ffmpeg process with pipes for efficient frame extraction, not separate processes per frame as you suggested.

Reply on news.ycombinator.com