More than half of the 2024 links, about 15, appeared between o1-preview’s September launch and a few days after o3’s late-December announcement. That span was arguably the most rapid period of advancement for these models in recent years.
DrNosferatu · 51m ago
AI has made FFmpeg easily usable to the mere mortal - that alone is a technological revolution.
rpdillon · 38m ago
Can vouch. Had an .mkv that browsers wouldn't play, and asked AI to give me a command line that maximized compatibility so I could stream it from CopyParty without folks on my network having to mount it and stream to VLC, rather than just play in the browser.
This is one of those cases where I couldn't really verify that what it suggested was correct:
I could look up all those flags, but I haven't. But the command did seem to work! I'm sure the HN crowd can critique. =)
And so I'm curious about the concept you're getting at: command line tools that offer natural language interfaces. Maybe the command line can become more broadly accessible, especially if designed with that that use case in mind.
DrNosferatu · 8m ago
I don’t know about the HN crowd, but my AI sure has things to say about your FFmpeg command:
<<
On the ffmpeg command,
• It’s conservative but works. The key bits for web playback are: H.264 video, yuv420p, AAC audio, MP4 container with +faststart. That’s exactly what it ensures.
• Where it’s sub‑optimal in 2025:
• profile/level: baseline, level 3.0 maximizes legacy compatibility but hurts efficiency/quality (no B‑frames, CABAC, etc.). High, level 4.0 (or auto) is widely supported on modern browsers/devices.
• quality control: better to use CRF + preset than implicit defaults. Example: -crf 20 -preset veryfast (or slow if you can wait).
• scaling: forcing even dimensions is fine; you can also just let libx264 pad/scale as needed or do scale=ceil(iw/2)2:ceil(ih/2)2 to avoid rounding down.
• redundancy: -pix_fmt yuv420p is good; adding format=yuv420p in -vf is redundant if -pix_fmt is set.
• Practical “ladder” that minimizes work and preserves quality:
1. If codecs already web‑friendly, just remux: ffmpeg -i in.mkv -c copy -movflags +faststart out.mp4 (Works when video is H.264 yuv420p and audio is AAC.)
2. If video is OK but audio isn’t (e.g., AC3/Opus), transcode audio only: ffmpeg -i in.mkv -c:v copy -c:a aac -b:a 160k -movflags +faststart out.mp4
3. If video needs re-encode, use modern defaults: ffmpeg -i in.mkv -c:v libx264 -profile:v high -level 4.0 -pix_fmt yuv420p -crf 20 -preset veryfast -vf “scale=ceil(iw/2)2:ceil(ih/2)2” -c:a aac -b:a 160k -movflags +faststart out.mp4
4. If you have GPU/QSV and just need “good enough” fast: ffmpeg -hwaccel auto -i in.mkv -c:v h264_nvenc -preset p5 -rc vbr -cq 23 -b:v 5M -maxrate 8M -bufsize 10M -profile:v high -pix_fmt yuv420p -c:a aac -b:a 160k -movflags +faststart out.mp4
> forcing even dimensions is fine; you can also just let libx264 pad/scale as needed
This part is wrong, because libx264 will reject an input with odd width or height rather than padding or scaling it automatically.
> redundancy: -pix_fmt yuv420p is good; adding format=yuv420p in -vf is redundant if -pix_fmt is set.
This seems to have hallucinated a redundancy that isn't there.
DrNosferatu · 1m ago
It’s Perplexity on GPT5 reasoning - I get the feeling they water it down somehow…
reactordev · 16m ago
For sure. You downgraded the video to half the size, then blew it back up again, converted the audio, set the apple mov headers, and spit that sucker out as an mp4 with probably half the resolution in pixel density but hey - it played.
I would try it again without the pix_fmt flag, the vf flag (and string). No idea what -level 3.0 is as it’s not in the docs anywhere (hallucination?). The video filter scaling definitely needs to go if you want it to be as close to the original resolution.
Cool part is, it worked. Even with a bad flag or two, ffmpeg said “Hold my beer”
teraflop · 13m ago
> You downgraded the video to half the size, then blew it back up again
No, that's not what that command does. It performs a single rescaling that resizes the video dimensions to the next lower multiple of 2. e.g. it will resize an 801x601 pixel video to 800x600.
If the video size is already an even number of pixels, it's a no-op and doesn't lose any detail.
If the video size isn't already even, then the rescaling is necessary because H.264 doesn't support odd dimensions.
> No idea what -level 3.0 is as it’s not in the docs anywhere (hallucination?).
But synthesizing FFmpeg commands is not the total gain from “AI expenditure”, is it?
There are infinite similar use cases.
I guess the killer app (for AI coding) will be a framework to successfully structure projects in appropriately sized complexity morsels LLMs can efficiently chew through.
techpineapple · 1h ago
Is it increasing or decreasing? Need some graphs.
skybrian · 1h ago
What should they graph? It's a list of AI-skeptical articles. I don't think we can conclude anything from that.
jppope · 57m ago
that can probably help indicate where we are in the hype cycle
boombapoom · 1h ago
ironic this was built with replit
guluarte · 48m ago
who have guesses that glorified Markov chains are not the path to AGI
WanderPanda · 28m ago
you know whats a glorified Markov chain? The Universe
This is one of those cases where I couldn't really verify that what it suggested was correct:
I could look up all those flags, but I haven't. But the command did seem to work! I'm sure the HN crowd can critique. =)And so I'm curious about the concept you're getting at: command line tools that offer natural language interfaces. Maybe the command line can become more broadly accessible, especially if designed with that that use case in mind.
<< On the ffmpeg command,
• It’s conservative but works. The key bits for web playback are: H.264 video, yuv420p, AAC audio, MP4 container with +faststart. That’s exactly what it ensures.
• Where it’s sub‑optimal in 2025:
• profile/level: baseline, level 3.0 maximizes legacy compatibility but hurts efficiency/quality (no B‑frames, CABAC, etc.). High, level 4.0 (or auto) is widely supported on modern browsers/devices.
• quality control: better to use CRF + preset than implicit defaults. Example: -crf 20 -preset veryfast (or slow if you can wait).
• scaling: forcing even dimensions is fine; you can also just let libx264 pad/scale as needed or do scale=ceil(iw/2)2:ceil(ih/2)2 to avoid rounding down.
• redundancy: -pix_fmt yuv420p is good; adding format=yuv420p in -vf is redundant if -pix_fmt is set.
• Practical “ladder” that minimizes work and preserves quality:
1. If codecs already web‑friendly, just remux: ffmpeg -i in.mkv -c copy -movflags +faststart out.mp4 (Works when video is H.264 yuv420p and audio is AAC.)
2. If video is OK but audio isn’t (e.g., AC3/Opus), transcode audio only: ffmpeg -i in.mkv -c:v copy -c:a aac -b:a 160k -movflags +faststart out.mp4
3. If video needs re-encode, use modern defaults: ffmpeg -i in.mkv -c:v libx264 -profile:v high -level 4.0 -pix_fmt yuv420p -crf 20 -preset veryfast -vf “scale=ceil(iw/2)2:ceil(ih/2)2” -c:a aac -b:a 160k -movflags +faststart out.mp4
4. If you have GPU/QSV and just need “good enough” fast: ffmpeg -hwaccel auto -i in.mkv -c:v h264_nvenc -preset p5 -rc vbr -cq 23 -b:v 5M -maxrate 8M -bufsize 10M -profile:v high -pix_fmt yuv420p -c:a aac -b:a 160k -movflags +faststart out.mp4
• Quick verification after transcoding: ffprobe -v error -select_streams v:0 -show_entries stream=codec_name,profile,level,pix_fmt,width,height -of default=nw=1 out.mp4 >>
This part is wrong, because libx264 will reject an input with odd width or height rather than padding or scaling it automatically.
> redundancy: -pix_fmt yuv420p is good; adding format=yuv420p in -vf is redundant if -pix_fmt is set.
This seems to have hallucinated a redundancy that isn't there.
I would try it again without the pix_fmt flag, the vf flag (and string). No idea what -level 3.0 is as it’s not in the docs anywhere (hallucination?). The video filter scaling definitely needs to go if you want it to be as close to the original resolution.
Cool part is, it worked. Even with a bad flag or two, ffmpeg said “Hold my beer”
No, that's not what that command does. It performs a single rescaling that resizes the video dimensions to the next lower multiple of 2. e.g. it will resize an 801x601 pixel video to 800x600.
If the video size is already an even number of pixels, it's a no-op and doesn't lose any detail.
If the video size isn't already even, then the rescaling is necessary because H.264 doesn't support odd dimensions.
> No idea what -level 3.0 is as it’s not in the docs anywhere (hallucination?).
It's documented here: https://ffmpeg.org/ffmpeg-codecs.html#Options-40
There are infinite similar use cases.
I guess the killer app (for AI coding) will be a framework to successfully structure projects in appropriately sized complexity morsels LLMs can efficiently chew through.