No. There is impossible situation between filter and the main program, where the filter arguments are not used and the main line is left to deal with leftovers.
If you could actually read and study those two solutions, you could notice that the grok has moved that stuff into separate file.
If the tool provides the switches on the cli, and the cli cannot do the task which is possible not using the cli. Then the cli is broken. That's not a difficult thought to hold in your head.
The tool defines how to use itself. If it requires using a temporary files to bypass shell limitations that it has no control over, then that's how it should be done and not a broken behavior.
"I want to use blue and red on my multicolor pen at the same time and it's not working so clearly the pen is broken might fit in your head but the pen still isn't the problem...
I guess you're getting downvoted since the claim that "FFmpeg is now somewhat broken" remains unsubstantiated. You're relying on information from LLMs which by definition are closer to random guesses than anything else. Effectively, what you're saying is that you cannot be bothered to learn the actual, albeit complex, syntax of FFmpeg to solve your problem, which is totally fine and up to you, but your conclusion that the tool is broken is like saying "this car is broken" when you don't know how to operate it and drive.
The idea was of course that someone else, one with working brain could run the example script and discover the underlying issue, which is weird and more complex.
A great way to get help is to ask for it. I'd imagine the ffmpeg community would be a lot more open to helping you if you didn't start off by saying their tool is broken, though
It is clearly broken and very-very-very deeply so. On organizational level.
Quote Gemini:
This error is the "smoking gun." It confirms that no matter how we quote the command, your shell is treating the comma as a separator for the FFmpeg command itself rather than a character inside the filter.
Maybe I need to take a step back. If, and heavy on the if, you want to communicate issues with humans, you're doing it wrong. If you want to rely on LLMs (and look where that's getting you), by all means do it that way. With humans, they need to come to that conclusion on their own. An example is like this:
You: "I would like to remove blurry frames with ffmpeg. I think I want to use xyz method. Can anybody please help me craft the command?"
Them: "yes, here's the command" (and maybe it's exactly what the LLM output)
You: "it's giving this error code. Here's a snippet of my input file. Can you please check if that works on your end?"
Them: "oh wow you're absolutely right, this doesn't work, I'll put in the issue ticket"
This is a lot nicer than "something else told me how to use your tool and it's broken".
With all due respect, you're trusting LLMs to a delusional level... they love talking about "smoking guns", that part made me laugh. Like another user said, sounds like its admitting the issue is in the shell anyways. They dont have intimate documentation knowledge of everything, use it more as a launch pad to test ideas and better shape your understanding of a subject knowing that it gets things wrong alot.
Watching the zombifying effects of AI "think" for others in real time is depressing.
You are completely missing his point with his answer. His point was less about ffmpeg being broken or not, and more about the fact that if you can't have an opinion or input of your own beside parroting a advanced Markov chain generator, then you don't matter in the discussion.
Assuming I'm the he, that last part isn't exactly what I meant. I meant that there's not a good faith effort in partaking in the conversation. I disagree with blindly following the LLM but even if you do there are ways to productively get help with it.
Title should actually be:
''Filters for FFmpeg 8.0''
[flagged]
Are you claiming ffmpeg is broken because your LLM prompt produced a bad command?
No. There is impossible situation between filter and the main program, where the filter arguments are not used and the main line is left to deal with leftovers.
If you could actually read and study those two solutions, you could notice that the grok has moved that stuff into separate file.
So what you means is it's possible, just not the way you thought or wanted to, and the tool works just fine. Gotcha.
If the tool provides the switches on the cli, and the cli cannot do the task which is possible not using the cli. Then the cli is broken. That's not a difficult thought to hold in your head.
The tool defines how to use itself. If it requires using a temporary files to bypass shell limitations that it has no control over, then that's how it should be done and not a broken behavior.
"I want to use blue and red on my multicolor pen at the same time and it's not working so clearly the pen is broken might fit in your head but the pen still isn't the problem...
I guess you're getting downvoted since the claim that "FFmpeg is now somewhat broken" remains unsubstantiated. You're relying on information from LLMs which by definition are closer to random guesses than anything else. Effectively, what you're saying is that you cannot be bothered to learn the actual, albeit complex, syntax of FFmpeg to solve your problem, which is totally fine and up to you, but your conclusion that the tool is broken is like saying "this car is broken" when you don't know how to operate it and drive.
The idea was of course that someone else, one with working brain could run the example script and discover the underlying issue, which is weird and more complex.
A great way to get help is to ask for it. I'd imagine the ffmpeg community would be a lot more open to helping you if you didn't start off by saying their tool is broken, though
It is clearly broken and very-very-very deeply so. On organizational level.
Quote Gemini:
Maybe I need to take a step back. If, and heavy on the if, you want to communicate issues with humans, you're doing it wrong. If you want to rely on LLMs (and look where that's getting you), by all means do it that way. With humans, they need to come to that conclusion on their own. An example is like this:
You: "I would like to remove blurry frames with ffmpeg. I think I want to use xyz method. Can anybody please help me craft the command?"
Them: "yes, here's the command" (and maybe it's exactly what the LLM output)
You: "it's giving this error code. Here's a snippet of my input file. Can you please check if that works on your end?"
Them: "oh wow you're absolutely right, this doesn't work, I'll put in the issue ticket"
This is a lot nicer than "something else told me how to use your tool and it's broken".
Soooooooooo, your SHELL is having issues with quotes, not ffmpeg.
this is what happens when you let people who don't know what they're doing think they do
With all due respect, you're trusting LLMs to a delusional level... they love talking about "smoking guns", that part made me laugh. Like another user said, sounds like its admitting the issue is in the shell anyways. They dont have intimate documentation knowledge of everything, use it more as a launch pad to test ideas and better shape your understanding of a subject knowing that it gets things wrong alot.
Watching the zombifying effects of AI "think" for others in real time is depressing.
You are completely missing his point with his answer. His point was less about ffmpeg being broken or not, and more about the fact that if you can't have an opinion or input of your own beside parroting a advanced Markov chain generator, then you don't matter in the discussion.
Assuming I'm the he, that last part isn't exactly what I meant. I meant that there's not a good faith effort in partaking in the conversation. I disagree with blindly following the LLM but even if you do there are ways to productively get help with it.
Wouldn't be surprised if Gemini is proofing the HN comments too.
Your reliance on the random word generator is making the point of OP.
[flagged]