3 ms·

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

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 • 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 >>

teraflop 1y ago
> 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 1y ago
  It’s Perplexity on GPT5 reasoning - I get the feeling they water it down somehow…
- DrNosferatu 1y ago
  My AI accepts the padding criticism, but complains of unfairness about the other: • The earlier suggestion that libx264 might “pad/scale as needed” was wrong; explicit filters are required for odd dimensions, and choosing between pad, crop, or scale depends on whether borders or resampling are acceptable. • Calling -vf “format=yuv420p” redundant was imprecise; it’s often unnecessary in simple cases where -pix_fmt yuv420p suffices, but it is not “hallucinated” to note that both exist—one governs the filtergraph and the other the encoder output—so redundancy depends on the filter chain.
Lockal 1y ago
A lot of slop and not a single word about libx264. Why 2003 format? We spend years designing better formats, implementing hardware optimized algorithms, learning psychoacoustics, building actually streaming-friendly formats, adding thousands of CU to GPUs, end user still pulls crappy H.264 out of obsolete tutorials (this time with removed date of writing). Yes, AI will add "You are absolutely right!" and "Why it works", pull h264_nvenc out of thin air, but in the end you streamed crap as the input to LLM and got digested crap of second degree as an output.

teraflop 1y ago

> 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 1y ago
It’s Perplexity on GPT5 reasoning - I get the feeling they water it down somehow…
DrNosferatu 1y ago
My AI accepts the padding criticism, but complains of unfairness about the other: • The earlier suggestion that libx264 might “pad/scale as needed” was wrong; explicit filters are required for odd dimensions, and choosing between pad, crop, or scale depends on whether borders or resampling are acceptable. • Calling -vf “format=yuv420p” redundant was imprecise; it’s often unnecessary in simple cases where -pix_fmt yuv420p suffices, but it is not “hallucinated” to note that both exist—one governs the filtergraph and the other the encoder output—so redundancy depends on the filter chain.

Lockal 1y ago

A lot of slop and not a single word about libx264. Why 2003 format? We spend years designing better formats, implementing hardware optimized algorithms, learning psychoacoustics, building actually streaming-friendly formats, adding thousands of CU to GPUs, end user still pulls crappy H.264 out of obsolete tutorials (this time with removed date of writing). Yes, AI will add "You are absolutely right!" and "Why it works", pull h264_nvenc out of thin air, but in the end you streamed crap as the input to LLM and got digested crap of second degree as an output.