3 ms·
> 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
by 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 agoIt’s Perplexity on GPT5 reasoning - I get the feeling they water it down somehow…
- DrNosferatu 1y agoMy 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.