151–160 of 186 posts
Earlier quoted context omitted.
It seems ffmpeg uses the mailing list patch way of doing "PRs", which is... well it is what it is. It doesn't help me understand the process unless I just go through all the mailing list archives, I guess.
Ugh why? That is so old school
as long as it works for them...
Earlier quoted context omitted.
> exhaustively finding the best possible combination of QP/resolution pairs for an entire encoding ladder that also optimizes subjective quality – and not just MSE. This is unnecessary if the encoder is well-written. It's like how some people used to run multipass encoders 3 or 4 times just in case the result got better. You only need one analysis pass to find the optimal quality at a bitrate.
Sure, the whole point of CRF is to set a quality target and forget about it, or, with ABR, to be as good as you can with an average bitrate target (under constraints). But you can't do that across resolutions, e.g. do you pick the higher bitrate 360p version, or the lower bitrate 480p one, considering both coding artifacts and upscaling degradation?
I think it should be possible to decide in one shot in the codec though. My memory is that codecs (image and video) have tried implementing scalable resolutions before, but it didn't catch on simply because dropping resolution is almost never better than dropping bitrate.
Earlier quoted context omitted.
> Their dynamic optimization encoding framework - allocating more bits for complex scenes and fewer bits for simpler, quieter scenes: https://netflixtechblog.com/dynamic-optimizer-a-perceptual-v ... and https://netflixtechblog.com/optimized-shot-based-encodes-now ... This is overrated - of course that's how you do it, what else would you do? > Mean-squared-error (MSE), typically used for encoder decisions, is a numbe…
You're letting the video codec make all the decisions for bitrate allocation. Netflix tries to optimize the encoding parameters per shot/scene. from the dynamic optimization article: - A long video sequence is split in shots ("Shots are portions of video with a relatively short duration, coming from the same camera under fairly constant lighting and environment conditions.") - Each shot is encoded multiple times with…
That's the problem - if the encoding parameters need to be varied per scene, it means you've defined the wrong parameters. Using a fixed H264 QP is not on the rate-distortion frontier, so don't encode at constant QP then. That's why x264 has a different fixed quality setting called "ratefactor".
Earlier quoted context omitted.
You're letting the video codec make all the decisions for bitrate allocation. Netflix tries to optimize the encoding parameters per shot/scene. from the dynamic optimization article: - A long video sequence is split in shots ("Shots are portions of video with a relatively short duration, coming from the same camera under fairly constant lighting and environment conditions.") - Each shot is encoded multiple times with…
> You're letting the video codec make all the decisions for bitrate allocation. > Netflix tries to optimize the encoding parameters per shot/scene. That's the problem - if the encoding parameters need to be varied per scene, it means you've defined the wrong parameters. Using a fixed H264 QP is not on the rate-distortion frontier, so don't encode at constant QP then. That's why x264 has a different fixed quality sett…
Earlier quoted context omitted.
your idea also doesn't work with live streaming, and may also not work with inter-frame filters (depending on implementation). nonetheless, this exists already with those limitations: av1an and I believe vapoursynth work more or less the way you describe, except you don't actually need to load every chunk into memory, only the current frames. as I understand, this isn't a major priority for mainstream encoding pipeli…
It can work with live streaming, you just need to add N keyframes of latency. With low-latency livestreaming keyframes are often close together anyways so adding say 4s of latency to get 4x encoding speed may be a good tradeoff.
Does it mean that my FFMPEG H264 encoding until now was single threaded?
Earlier quoted context omitted.
https://www.youtube.com/watch?v=9kaIXkImCAM
"Do you know ffmpeg supports OCR? I haven't found the command yet, but it does support it." This is probably 80% of my experience with ffmpeg, to be honest, but the other 20% is invaluable enough anyway.
Earlier quoted context omitted.
> Their dynamic optimization encoding framework - allocating more bits for complex scenes and fewer bits for simpler, quieter scenes: https://netflixtechblog.com/dynamic-optimizer-a-perceptual-v ... and https://netflixtechblog.com/optimized-shot-based-encodes-now ... This is overrated - of course that's how you do it, what else would you do? > Mean-squared-error (MSE), typically used for encoder decisions, is a numbe…
You're letting the video codec make all the decisions for bitrate allocation. Netflix tries to optimize the encoding parameters per shot/scene. from the dynamic optimization article: - A long video sequence is split in shots ("Shots are portions of video with a relatively short duration, coming from the same camera under fairly constant lighting and environment conditions.") - Each shot is encoded multiple times with…
Possibly Netflix statistics are way better.
A theory about this that may also affect other older solid software: the assumptions made on where to optimally "split" a problem for multi-threading/processing has likely changed over time. It wasn't that long ago that reading, processing, and rendering the contents of a single image took a noticeable amount of time. But both hardware and software techniques have gotten significantly faster. What may have made sense…