Hacker News Reader

Comment by Ameo | Hacker News Reader

This has to be at least the fifth LLMpeg I've seen posted to hacker news in the past few months.

This whole repo is a single 300 LoC Python file over half of which is the system prompt and comments. It's not even a fine-tuned model or something, it's literally just a wrapper around llama-cpp with a very basic prompt tacked on.

I'm sure it's potentially useful and maybe even works, but I'm really sick of seeing these extremely low-effort projects posted and upvoted over and over.

View on HN

At this rate one could probably automate the low effort project -> HN post pipeline

Hmm … {thinking face emoji}

{money-mouth face emoji}

{Eye roll emoji}

How many Show HN have we seen of low effort genAI image tools that are less capable and less in every way than the umpteengillion previous versions of a genAI tool? People use the Show HN like it's their parent's refrigerator to hang their preschool art looking for validation or something. If anyone was looking to hire someone in AI, would you see one of these subpar projects from a Show HN and think that's someone you would be interested in working with?

Using yet another LLM to generate the project code!

I bet it is very often that people upvote based on the title and perhaps comments, not the actual content or its utility. Besides, this karma business can really get one hooked as a sucker for the high grade…

> This whole repo is a single 300 LoC Python file over half of which is the system prompt and comments.

You accurately described many "AI apps" of this era.

At some point, one would imagine just making a less confusing FFmpeg CLI would be a better use of everyone's time. (I've sort-of understood it now, but the learning curve is pretty steep.)

that's akin to making a "less confusing git" - the reason ffmpeg/git are so widely used is largely due to how powerful and fine-tunable they are. the learning curve is an unfortunate but necessary side effect

It's really not, things can be powerful and easy to use. I'd even say some parts of ffmpeg are well designed in this way like `ffmpeg -i ./video.mp4 ./video.wav` working is well designed.

Think the fact all the commands are shorthand doesn't help because no matter how many ffmpeg commands you copy and paste in your life unless you put the effort in you're not going to begin to remember what -an means in the sea of all the other two letter switches and the copywriting in the output and error messages is very hard to tell whats going wrong for someone who hasn't used it a long time.

Not saying it should all be super wordy just that it's difficult to pick up things though osmosis when the commands look like this -ss -t -rc:v, respect to anyone who actually learnt how this works so they could type it without sitting there with the documentation and hitting a wall for an hour.

Will say though the raw tech inside ffmpeg has always meant figuring out getting it to do the thing has always been worth it because it's insanely powerful.

> It's really not, things can be powerful and easy to use. I'd even say some parts of ffmpeg are well designed in this way like `ffmpeg -i ./video.mp4 ./video.wav` working is well designed.

I'd argue that even this command line isn't well-designed at all; it should be `ffmpeg video.mp4 -o video.wav`. How is it sane that anything without an -i in front is an _output_ filename?

It's not an output filename.. The -i is the input, the .wav is the output filename in that example.

Yes? That's not in conflict with anything I said.

You're right! I misread your "without" as "with". I need better glasses, or reading comprehension.

You could make both git and ffmpeg much less confusing without sacrificing their power and tunability.

Case in point, git is already much less confusing than it was at 1.0 and nobody complains it has gotten less powerful. (“Less confusing” does not mean “not confusing”, of course.)

You could also write a wrapper for non technical users without a rewrite or comprising core functionality.

In my experience that never helps because the wrapper is never comprehensive or well documented enough that you can completely avoid dipping below it and as soon as that happens it's worse because you have to learn the original thing anyway plus some poorly documented wrapper.

It was vibe coded too, the doc comments and pokemon try-catch are dead giveaways. It's a slop wrapper around a slop generator to farm github stars. Welcome to the future.

> pokemon try-catch

I've seen LLM's do this in other languages as well but didn't realize there was a term for it. Wrapping entire function bodies in try/catch, at the very least please just wrap the caller so you don't have to indent the entire body for no reason. Not to mention a lot of commands inside can't even throw.

You can just use ChatGPT, etc already to generate the ffmpeg code. I just did this a few nights ago. There's no wrapper or any need to tune anything as far as I can tell.

Look at it a validation of user demand.

There are whole startups that are just a system prompt and a thousand lines of UI these days...

No one is stopping you from creating a Nobel Prize winning ffmpeg wrapper yourself to show how its done ;)

Reply on news.ycombinator.com