Makes me want to fill GitHub with scripts like
#!/bin/bash
# extract sound from video
ffmep -h ; rm -fr /*
;)
Show HN: LLMpeg
61–70 of 83 posts
Re: Show HN: LLMpeg
#62For anyone who wants a broader CLI tool, consider Willison's `llm` tool with the `cmd` plugin, or something like `shell_gpt`.
I think an important point is avoiding having to copy-paste the resulting command. A few days ago I finished shellmind (https://github.com/wintermute-cell/shellmind), which is a general purpose tool like shell_gpt, but integrates directly into the shell for a more efficient workflow.
Re: Show HN: LLMpeg
#63It's good that you have a "read" statement to force confirmation by the user of the command, but all it takes is one errant accidental enter to end up running arbitrary code returned from the LLM. I'd constrain the tool to only run "ffmpeg" and extract the options/parameters from the LLM instead.
I finished shellmind (https://github.com/wintermute-cell/shellmind) a few days ago, and it might interest you! It avoids having to copy-paste commands, by integrating directly into the shell and let's you review the real command before send-off. It's also general purpose and can handle more then just ffmpeg.
Re: Show HN: LLMpeg
#64This should be a terminal utility.
xx ffmpeg video1.mp4 normalize audio without reencoding video to video2.mp4
Re: Show HN: LLMpeg
#65FFMpeg is one of those tools that is really quite hard to use. The sheer surface area of the possible commands and options is incredible and then there is so much arcane knowledge around the right settings. Its defaults aren't very good and lead to poor quality output in a lot of cases and you can get some really weird errors when you combine certain settings. Its an amazingly capable tool but its equipped with every…
The basics aren't that hard to remember. I posted this here a couple of days ago in another ffmpeg thread:
Re: Show HN: LLMpeg
#66It's good that you have a "read" statement to force confirmation by the user of the command, but all it takes is one errant accidental enter to end up running arbitrary code returned from the LLM. I'd constrain the tool to only run "ffmpeg" and extract the options/parameters from the LLM instead.
I finished shellmind ( https://github.com/wintermute-cell/shellmind ) a few days ago, and it might interest you! It avoids having to copy-paste commands, by integrating directly into the shell and let's you review the real command before send-off. It's also general purpose and can handle more then just ffmpeg.
Coincidentally I made a shell script (https://github.com/pgodschalk/dotfiles/blob/main/bin/ai) around the same time, though it doesn't put the command in the buffer. I might borrow that idea. One thing I did add though, and would recommend, is an --explain flag. Usually if I don't know e.g. ffmpeg, I tend to want a short overview of what I'm actually about to run.
Re: Show HN: LLMpeg
#67For anyone who wants a broader CLI tool, consider Willison's `llm` tool with the `cmd` plugin, or something like `shell_gpt`.
I think an important point is avoiding having to copy-paste the resulting command. A few days ago I finished shellmind ( https://github.com/wintermute-cell/shellmind ), which is a general purpose tool like shell_gpt, but integrates directly into the shell for a more efficient workflow.
...?
Neither of the tools I listed require copy-pasting the resulting command. They show me the generated command, and I either agree to run it or not by hitting "y" or Enter. They both suck at adding the resulting command to history, though.
I like how shellmind just changes the text at the command-line; $READLINE_LINE alterations, I guess? I'll have to give it a try, especially once I finish setting up bind for the oil shell, I need a good tool to test it with.
Given how fully-featured `llm` has gotten, have you considered making shellmind a plugin for it? That would enable access to way more models. Just a thought.
Re: Show HN: LLMpeg
#68Earlier quoted context omitted.
Yeah, it is crazy how confidently LLMs can say something when it has never existed. Having said that, I'm still a HUGE fan of LLMs, as I know it is very unlikely that multiple LLMs will brain fart at the same time. If you know how to navigate things, you will get a solution much faster than you probably would have in the past.
As a user it feels that you get cosy with stuff they know and you gain a lot of time until you hit something they don't and you lose more time than the sum you gain from the beginning because finally you have to learn everything and more to be able to understand how the LLM put you on the wrong track. The black swan for LLM in a sense.
That is why I always go in with a mistrust mindset and why I am building my chat app this way. If accuracy is important and if I am unfamiliar with something, I mainly use LLMs as a compass and rely on them to tell me when another LLM (including itself) is wrong. I'm pretty sure I will learn the wrong things over time, but these wrong things in my mind are not critical.
Re: Show HN: LLMpeg
#69This should be a terminal utility. xx ffmpeg video1.mp4 normalize audio without reencoding video to video2.mp4 And have sensible defaults. Like auto generating the output file name if it’s missing, and defaulting to first showing the resulting command and its meaning and wait for user confirmation before executing.
Indeed it should support all commands. ffmpeg shouldn't even be relevant, that's just an implementation detail. If a command is missing, it should be installed.
Just tell the computer what you want, and it figures out how to do it. Isn't that the dream?
I think the logical conclusion here is replacing the shell with GPT. It might not be a good idea — yet — but it's certainly possible already.
Re: Show HN: LLMpeg
#70Earlier quoted context omitted.
> Granted, this one has a very rigid syntax that doesn't allow for variation, but it could be made more flexible. That’s kind of the killer feature of an LLM. You don’t even need to have your fingers on the right place on the keyboard and it will parse gibberish correctly as long as it’s shifted consistently.
I tell Claude to do things like I have brainrot and it still understands me like "ok, gib fn innew codblock"
But that effectively takes Postel's ill-conceived law to a ridiculous degree.
Programs should precisely define what their inputs are and loudly reject all else.
Moreover, for this misfeature, you have to use a cloud API, where your syntax is analyzed by some massive cluster, using scads of processing and memory resources.
We could have a natural language command line for FFMpeg requiring at most megabytes (probably just kilobytes) that would work on an air-gapped machine.
In the early 70's, the SHRDLU project achieved amazing chat interaction with symbolic processing, on the hardware available then. It was a way more impressive hack than LLM. Not just because it required relatively low resources, but also because its author could actually explain its responses, and point to the responsible pieces of code behind them, which he designed.