So that tells me that I still don't have StaxRip pointing to the right ffmpeg.exe. But when I try the advanced options to choose 10-bits, I'm still getting errors when it runs, where FFMPEG isn't recognizing parameters like "-pix_fmt yuv420p10" or "output-depth=10" or "-profile:v main10." I copied the ffmpeg.exe from the media autobuild into the StaxRip FFmpeg folder and restarted. Confirmed that it compiled correctly and supported 10bits. I downloaded and compiles the Media Autobuild Suite, which had an x265 that supported 10-bit and 12-bit.
And thats when I discovered the ffmpeg x265 didn't support 10-bit encoding natively. Thats what i had suspected, but wanted to confirm.įollowing up on that, I was trying to figure out why using x265 was taking significantly different amounts of time than using the ffmpeg x265, so i wanted to run some A/B tests. In general, "PointResize" will probably be the least preferred choice, except for resizing pixel - Thanks for the info. Compare them, get a feeling how much you like which. But I believe those are more interesting for computer generated videos? Not sure. It may require manual editing of the scvript. And I believe StaxRip does not even offer this two-step technique. If you have several similar functions with different numbers: The higher numbers usually cause a "sharper" image but more artifacts and more exaggerated noise.įor cartoons I would recommend NNEDI3's rpow2 resize first and then a downscale with Spline16. For general content I would suggest neutral or soft bicubic, or Spline16, which avoids too much ringing. Some people like it "sharp" and prefer Lanczos, others don't like the exaggeration of noise and edge ringing. Different material may make you prefer different resampler kernels because they differ in the amount of smoothing or "sharpening" (with the side effects of adding ringing artifacts around borders).
0 kommentar(er)
