Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: LLMpeg

github.com

Post reply on HN
Print view View original

71–80 of 83 posts

Re: Show HN: LLMpeg

#71

Post by sitkack »

andai wrote: post #45
sitkack wrote: post #37

Earlier quoted context omitted.

Do you envision the LLMs creating a protocol? Would the caller supply the schema for the response?

I mentioned here recently that I let LLMs design the APIs which they are going to use. I got quite a negative response to that, which surprised me.

I see it here https://news.ycombinator.com/item?id=42548228

HN and internet forums in general have a contagion of critique, where we mercilessly point out flaws and attempt to show our superiority. It best to ignore them.

> I ask the LLM to build it. That way, by definition, the LLM has a built in understanding of how the system should work, because the LLM itself invented it.

I share the same belief, and as a rebuttal against EagnaIonat's comment, when you ask the LLM to create something, it is finding the centroid of the latent space of your request in its high dimensional space. The output is congruent with what it knows and believes. So yes, the output would be statistical, but is also embedded in its subspace. For code you have written independent of the LLM, that isn't necessarily true.

I think there are many ways we could test this, even in smaller models through constructed tests and reprojection of output programs.

It is like if I asked an OO programmer to come up with a purely functional solution, it would be hard. And then if I asked to take an existing PFP program and refactor and extend it, it would be broken.

Solutions have to exist in the natural space, this is true for everyone.

Re: Show HN: LLMpeg

#72

Post by halJordan »

andai wrote: post #69
leobg wrote: post #64

This 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.

There are already bash replacements and cli tools doing this. The main thing here is how acerbic the anti-AI luddites that prevent the knowledge of this stuff from propagating

Re: Show HN: LLMpeg

#73

Post by halJordan »

sitkack wrote: post #37
davmar wrote: post #9

i think this type of interaction is the future in lots of areas. i can imagine we replace API's completely with a single endpoint where you hit it up with a description of what you want back. like, hit up 'news.ycombinator.com/api' with "give me all the highest rated submissions over the past week about LLMs". a server side LLM translates that to SQL, executes the query, returns the results. this approach is broadly…

Do you envision the LLMs creating a protocol? Would the caller supply the schema for the response?

The big protocol doing this is called "Model Context Protocol" and it should've been a widely read/discussed post except hn has taken a wide anti-ai stance

Re: Show HN: LLMpeg

#75

Post by varenc »

bambax wrote: post #65
PaulKeeble wrote: post #13

FFMpeg 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: https://news.ycombinator.com/item?id=42708088

great intro guide!

I'd say another big tip is getting proper ffmpeg completion into your shell. That's helpful for seeing a list of all possible encoders, pixel formats, etc.

I also found that playing around with filters in mpv was a great what to learn the ffmpeg filter expression language!

Re: Show HN: LLMpeg

#76

Post by magistr4te »

KingMob wrote: post #67
magistr4te wrote: post #62

Earlier quoted context omitted.

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…

Ah, thank you for the correction. It's been quite a while since I used shell_gpt and things seem to have changed; I need to revisit these tools :) Your plugin suggestion sounds interesting, I'll consider it!

Re: Show HN: LLMpeg

#77

Post by sovok »

magistr4te wrote: post #63
vunderba wrote: post #12

It'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.

Seems to be a common thing. I did something similar two days ago. Pretty helpful so far: https://github.com/combatwombat/cmdline-ai-helper

Re: Show HN: LLMpeg

#78

Post by adwn »

kazinator wrote: post #70
airstrike wrote: post #15

Earlier quoted context omitted.

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 j…

> Programs should precisely define what their inputs are and loudly reject all else.

…when interfacing with other programs. Humans aren't programs, which is a somewhat important distinction.

Re: Show HN: LLMpeg

#79

Post by vishnuharidas »

I am eagerly waiting for software test frameworks to adapt LLM where I can simply write test cases as easy as - "Open the website, login using these credentials, click the logout button, go back to the previous page, and check if the user is not logged in" - and let the LLM do the job.

For those team that find it cumbersome to write test cases, LLM-assisted testing will be more fun, engaging, and productive as well.

Re: Show HN: LLMpeg

#80

Post by kazinator »

adwn wrote: post #78
kazinator wrote: post #70

Earlier quoted context omitted.

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 j…

> Programs should precisely define what their inputs are and loudly reject all else. …when interfacing with other programs. Humans aren't programs, which is a somewhat important distinction.

Well, firstly, take a look at some tech news, because it sure looks to me like people left and right are interfacing programs with AI, desperately scrambling to get reliable, stable outputs out of their prompts.

Secondly, people need precision and stability in program behavior also. People learn that when they give a certain command, they get a certain effect, and they don't want it to break.

Interfaces that allow people to express some wish in many ways (language, direct manipulation, ...) can still be rigidly defined: appear flexible to the casual user, but rigid to someone who cares to study the several thousand rules under the hood (or whatever).

Post reply on HN