Page MenuHome

FFmpeg interface improvements
ClosedPublic

Authored by Sybren A. Stüvel (sybren) on Sep 18 2016, 1:09 PM.

Details

Summary

This patch changes a couple of things in the video output encoding.

  • Clearer separation between container and codec. No more "format", as this is too ambiguous. As a result, codecs were removed from the container list.
  • Added FFmpeg speed presets, so the user can choosen from the range "Very slow" to "Ultra fast". By default no preset is used.
  • Added Constant Rate Factor (CRF) mode, which allows changing the bit-rate depending on the desired quality and the input. This generally produces the best quality videos, at the expense of not knowing the exact bit-rate and file size.
  • Added optional maximum of non-B-frames between B-frames (max_b_frames).
  • Presets were adjusted for these changes, and new presets added. One of the new presets is recommended for reviewing videos, as it allows players to scrub through it easily. Might be nice in weeklies. This preset also requires control over the max_b_frames setting.

GUI-only changes:

  • Renamed "MPEG" in the output file format menu with "FFmpeg", as this is more accurate. After all, FFmpeg is used when this option is chosen, which can also output non-MPEG files.
  • Certain parts of the GUI are disabled when not in use:
    • bit rate options are not used when a constant rate factor is given.
    • audio bitrate & volume are not used when no audio is exported.

Note that I did not touch BKE_ffmpeg_preset_set(). There are currently
two preset systems for FFmpeg (BKE_ffmpeg_preset_set() and the Python
preset system). Before we do more work on BKE_ffmpeg_preset_set(), I think
it's a good idea to determine whether we want to keep it at all.

After this patch has been accepted, I'd be happy to go through the code and remove any then-obsolete bits, such as the handling of "XVID" as a container format.

Diff Detail

Repository
rB Blender

Event Timeline

Sybren A. Stüvel (sybren) retitled this revision from to FFmpeg interface improvements.
Sybren A. Stüvel (sybren) updated this object.
Sybren A. Stüvel (sybren) set the repository for this revision to rB Blender.
Sybren A. Stüvel (sybren) updated this object.
Sybren A. Stüvel (sybren) updated this object.
Brecht Van Lommel (brecht) added inline comments.
source/blender/makesrna/intern/rna_scene.c
285–294

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.

5491–5497

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".

source/blender/makesrna/intern/rna_scene.c
285–294

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.

5491–5497

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.

source/blender/makesrna/intern/rna_scene.c
285–294

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.

5491–5497

I like Encoding Speed as a name.

source/blender/makesrna/intern/rna_scene.c
285–294

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.

source/blender/makesrna/intern/rna_scene.c
285–294

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.

Sybren A. Stüvel (sybren) updated this object.

Renamed presets to encode speed, and removed the 'None' encode speed in favour of simply defaulting to 'medium'

  • Present CRF as EnumItems, so that people can choose a quality instead of a number
  • "medium" → "medium speed"
  • Layout & labeling tweaks
  • No longer use FFMPEG_LOSSLESS_OUTPUT for h.264 (use crf=0 instead)

I've renamed "constant rate factor" in the GUI to "output quality", as most people won't know what CRF means. I did keep it in the tooltip so that people that do know can recognise it. Also made some other GUI tweaks, and changed the code to use CRF=0 to switch to lossless in h.264. This has the advantage that the user can no longer enable lossless AND set a bitrate (the two are conceptually mutually exclusive).

I think it's ready for a re-review now :)

Brecht Van Lommel (brecht) requested changes to this revision.Sep 18 2016, 10:38 PM

I like it. I'd but constant rate factor above encoding speed, since I think that's the more important setting.

source/blender/makesrna/intern/rna_scene.c
5357

Don't add "; default", we don't do that for other options either. Users can reset to default if they want to know the default.

This revision now requires changes to proceed.Sep 18 2016, 10:38 PM
Sybren A. Stüvel (sybren) edited edge metadata.
  • Fixed defaults for versioning, startup file and RNA
  • Fixed & clarified some ffmpeg presets
  • Updated labels
  • Changed "FFmpeg" to "FFmpeg video" to make it a bit more intuitive for people that don't know FFmpeg.
Sybren A. Stüvel (sybren) edited edge metadata.
  • Renamed the "h264 for review" preset so its intended use is more explicit.
This revision was automatically updated to reflect the committed changes.

Pushed to master after verbal acceptance by @Sergey Sharybin (sergey)

Sybren A. Stüvel (sybren) marked 3 inline comments as done.Sep 21 2016, 3:30 PM

Is there a plan to fully define all the allowed combinations of containers, video and audio codecs, and their individual parameters? Maybe in some easily editable xml file.

Right now there are a lot of cases where user UI choices are ignored by the backend as it wouldn't create a valid stream. Or if not ignored, the nearest available value is chosen (eg, if user chooses 130kbps mp3, 128 is used).

I've just found T44468

There are a couple of issues being conflated on that ticket;

  • whether Blender's UI shows only valid combinations (valid defined by the container/codec standards)
  • whether a valid stream rendered out by Blender is playable in X media player

The second doesn't impact the first at all.

Just wondering what people's thoughts are on this.

Is there a plan to fully define all the allowed combinations of containers, video and audio codecs, and their individual parameters? Maybe in some easily editable xml file.

IMO "easily editable xml" doesn't exist.

I've just found T44468 [...] Just wondering what people's thoughts are on this.

I agree with Sergey's comment T44468#304513.

Hi @Sybren A. Stüvel (sybren) after this commit we are having T50057 problem, what would be the best solution to set it up correctly? So that screen cast doesn't fail?

Let's discuss that ticket at that ticket, and not here.