4 ms·

I can't help but find it kinda humorous that if the 119 lines of the system prompt wasn't there, it would just be a generic script that takes your input, sends

I can't help but find it kinda humorous that if the 119 lines of the system prompt wasn't there, it would just be a generic script that takes your input, sends it to ollama and then system("...") the response after some light processing. https://github.com/scottvr/wtffmpeg/blob/main/wtffmpeg.py#L9-L120 https://github.com/scottvr/wtffmpeg/blob/main/wtffmpeg.py#L9... >You are an expert at writing commands for the `ffmpeg` multimedia framework. >Respond ONLY with the `ffmpeg` command. Do not add any explanations, introductory text, or markdown formatting. Fragility of it aside, and the fact that more is written to try and force it to do less, this is basically the gist of the whole thing.

dylan604 1y ago
The first example from your link - User: "convert input.mov to a web-friendly mp4" - Assistant: ffmpeg -i input.mov -c:v libx264 -preset medium -crf 23 -c:a aac -b:a 128k output.mp4 Isn't exactly a web-friendly mp4. the fast start option is not used. this means the MooV header is at the end of the file instead of the head. that means the entire file must be read/scanned to get to the metadata when the browser requests it which means a long delay depending on the size of the file. - User: "create a 10-second clip from my_movie.mkv starting at the 1 minute 30 second mark" - Assistant: ffmpeg -i my_movie.mkv -ss 00:01:30 -t 10 -c copy clip.mkv this is another poor example, as it is again the slowest option by having the -ss after the -i. placing the -ss before the -i will result in the command being faster. not really sure who is training this system on how to use ffmpeg, but it doesn't fill me with confidence that simple things like this are being missed. after this example, i just stopped looking
- oefrha 1y ago
  > that means the entire file must be read/scanned to get to the metadata when the browser requests it which means a long delay depending on the size of the file. Not really, unless your server doesn’t support range requests, browsers are smart enough to request the end of the file where a non-faststart moov atom typically lives. But yes, you should use faststart. You’re right that this appears to be the work of someone who’s not very adept at ffmpeg. Which shouldn’t be surprising; as a power user, maybe even expert at ffmpeg, unless I need to write a complex filter graph, consulting an LLM will just slow me down—people like me have no need for this.
  - dylan604 1y ago
    > Not really, unless That's great if you built the server and know this. If you are just providing files for someone to use in a location you know nothing about, best practices for web-friendly is to have the MooV at the head of the file. Placing it at the end is just asking for trouble. Anyone that's been there done that and experienced MooV at the end one time will always move it to the head from then on. An LLM should know this. Someone training an LLM should know this. Making a tool like this that does not do best practices is just a bad tool. Arguing against best practices verges on making one a tool themself. Don't be a tool

dylan604 1y ago

The first example from your link - User: "convert input.mov to a web-friendly mp4" - Assistant: ffmpeg -i input.mov -c:v libx264 -preset medium -crf 23 -c:a aac -b:a 128k output.mp4 Isn't exactly a web-friendly mp4. the fast start option is not used. this means the MooV header is at the end of the file instead of the head. that means the entire file must be read/scanned to get to the metadata when the browser requests it which means a long delay depending on the size of the file. - User: "create a 10-second clip from my_movie.mkv starting at the 1 minute 30 second mark" - Assistant: ffmpeg -i my_movie.mkv -ss 00:01:30 -t 10 -c copy clip.mkv this is another poor example, as it is again the slowest option by having the -ss after the -i. placing the -ss before the -i will result in the command being faster. not really sure who is training this system on how to use ffmpeg, but it doesn't fill me with confidence that simple things like this are being missed. after this example, i just stopped looking

oefrha 1y ago
> that means the entire file must be read/scanned to get to the metadata when the browser requests it which means a long delay depending on the size of the file. Not really, unless your server doesn’t support range requests, browsers are smart enough to request the end of the file where a non-faststart moov atom typically lives. But yes, you should use faststart. You’re right that this appears to be the work of someone who’s not very adept at ffmpeg. Which shouldn’t be surprising; as a power user, maybe even expert at ffmpeg, unless I need to write a complex filter graph, consulting an LLM will just slow me down—people like me have no need for this.
- dylan604 1y ago
  > Not really, unless That's great if you built the server and know this. If you are just providing files for someone to use in a location you know nothing about, best practices for web-friendly is to have the MooV at the head of the file. Placing it at the end is just asking for trouble. Anyone that's been there done that and experienced MooV at the end one time will always move it to the head from then on. An LLM should know this. Someone training an LLM should know this. Making a tool like this that does not do best practices is just a bad tool. Arguing against best practices verges on making one a tool themself. Don't be a tool