Originally the way I wanted these presets to work is that you'd have a couple simple ones like H.264, Ogg Theora, Xvid, with good defaults and a single quality slider, and leave FFmpeg as an advanced choice. We didn't quite get there though.

I don't think the average user even knows what FFmpeg, and shouldn't have to know. So from that point of view it would be nice if the python presets could still be in this menu, perhaps even with a quality slider that drivers the other settings interactively, but that would require custom code.

This is going back in the direction of the previous system where the user is exposed to all these options that I don't even have any idea how to tweak properly. Which might still be better than the unfinished thing we have now, but I wanted to explain the original rationale.

The name is confusing in my opinion since we already have another type of preset and this is not like that. I would use something like "Performance".

Originally the way I wanted these presets to work is that you'd have a couple simple ones like H.264, Ogg Theora, Xvid, with good defaults and a single quality slider, and leave FFmpeg as an advanced choice. We didn't quite get there though.

I think that would be a good approach, if we had it ;-)

I don't think the average user even knows what FFmpeg, and shouldn't have to know.

In my personal opinion, we could just remove all non-FFmpeg options and always use FFmpeg. That way we simplify things greatly. With the wide range of possible codecs/containers FFmpeg supports, I don't think we really lose any actual functionality.

So from that point of view it would be nice if the python presets could still be in this menu, perhaps even with a quality slider that drivers the other settings interactively, but that would require custom code.

This is going back in the direction of the previous system where the user is exposed to all these options that I don't even have any idea how to tweak properly.

Not quite. Instead of having these options that I also don't know how to tweak properly

• bitrate
• minimum bitrate
• maximum bitrate
• buffer size
• mux rate
• mux packet size

I'm giving the user just this one option:

• Constant rate factor

To me this seems to be a step forward towards the single quality slider. As far as I'm concerned I'd be happy to remove all options in the previous list, and just keep the CRF option.

The "keyframe interval" (already existed, but I renamed "GOP size" to "keyframe interval") and "max B-frames" (new) options are needed to create an output file that can be scrubbed through.

Which might still be better than the unfinished thing we have now, but I wanted to explain the original rationale.

Thanks for that.

I agree, but "performance" might not be the best label -- after all, it's a balance between performance (quick compression = done faster = high performance) and performance (good compression = smaller file = high performance). Maybe "encoding speed" is better, as it matches the choices given to the user.

In my personal opinion, we could just remove all non-FFmpeg options and always use FFmpeg. That way we simplify things greatly. With the wide range of possible codecs/containers FFmpeg supports, I don't think we really lose any actual functionality.

I agree, as far as I'm concerned we can remove builtin AVI and Quicktime.

I'm giving the user just this one option:

• Constant rate factor

That's great! I missed that aspect. I'd almost be inclined to rename that to Quality and map it 0..100%.

The "keyframe interval" (already existed, but I renamed "GOP size" to "keyframe interval") and "max B-frames" (new) options are needed to create an output file that can be scrubbed through.

Might be good to mention in the property description that these options affect how well scrubbing works.

I like Encoding Speed as a name.

That's great! I missed that aspect. I'd almost be inclined to rename that to Quality and map it 0..100%.

That seems a good idea at first, especially since the CRF numbers would be different when we output 10-bit (per colour per pixel) video. Using an intermediate value would allow Blender to recompute the appropriate CRF given the output format.

However, it has some issues. The CRF number is exponential; +6 is roughly half the bitrate while -6 is roughly twice the bitrate [ref]. We can map the 0..100% range to 51..0, but as a naieve user I would expect a percentage to work linear, not exponential. Having a "quality increase" of 11% would correspond to -6 on the CRF number, doubling the bitrate. Furthermore, CRF=23 is a fine default value, which would correspond to 45%; it doesn't seem that good any more.

I have to conclude that turning it into a quality percentage doesn't make it easier to understand to novice users, while it makes things harder to understand to those people that actually know about CRF and video encoding.

If we stick to the CRF value, we might want to soft clamp it to a reasonable range (18-28?).

We don't need to use a linear mapping, and the fact that values are not particularly intuitive seems to me like an argument in favor of remapping them. But representing it as a 0..100% is also a bit deceptive if 18 is already perceptually lossless, there is no percentage value that intuitively corresponds to that.

Perhaps there could be some quality presets, or the UI could show one of multiple labels like this depending on the chosen CRF value: Very Low Quality / Low Quality / Medium Quality / Good Quality / High Quality / Perceptually Lossless / Lossless.