From BlenderWiki

Fixing Blender's Output Interface

Since version 2.71 the UI for setting video output parameters is confusing and inconsistent. The workflow is scattered, options in many contexts are misleading, and the presets are largely useless. I am an animator, not a developer, so I have no way of actually seeing this proposal through to a finished patch in Blender. I just thought some feedback might be appreciated and hopefully some of the Blender devs will find this useful.

Issues With Current System

Here are some of the problems with the current interface for outputting media that I ran into.

Current Interface. The above combination of codecs and containers is invalid and produces an unplayable video. Context from menu selections is ignored and the user is offered no guidance.

1. File Formats The main issue here is with the Movie formats. "Format" is itself kind of a loose term when describing a movie file as it can be used interchangeably to describe both the container and the codec. The container is the first thing a user would expect to have to select when choosing a video format, but not all of the menu items here are containers. H.264 for example is a codec that can go into many different container types. "Frame Server" is not a format at all. The last 4 items (H.264, MPEG, Ogg Theora, Xvid) seem only to act as presets when clicked. After being selected they have no further effect.

2. Encoder Presets Who uses these? Why do presets for H264, Theora, and Xvid exist both, here and in the previous menu? Being able to add custom presets without digging into the .py files would be a great feature here, or at least better presets with more helpful names.

3. "Formats" and Codecs The difference between this menu and the previous one is unclear and/or ambiguous. Some of these "formats" look like codecs. Selecting H.264 in this menu just makes an .avi with H.264 encoding, just like selecting "AVI" and then "H.264". There is no guidance for the user about which containers support which codecs (see this reference: [1]).

4. Compression Parameters How useful is it to expose values like "Mux Rate" and "Packet Size" to the user? (This is not a rhetorical question; I really don't know!) Other video applications do not prompt the user for some of these values. Hopefully someone more knowledgeable than me in this area can suggest improvements; like the person who developed this area in the first place. What I do know is that bit rate settings have no place below lossless codecs, like the one selected in this case. It also seems strange that bit rate values are soft-limited at 10 Mbits/s when many videos can have much higher bit rates than that. Options for fixed-quality compression for lossy codecs would be nice as well.

5. Audio Encoding Again, the example here shows bit rate settings for a lossless codec which makes no sense. It would make more sense to select from a conventional list of bit rates (128, 160, 192, etc.) rather than allow to set an arbitrary integer.

Improvement proposal

Here is an example of how the UI could look like:

1. Output Type The foremost decision a user makes is whether they're exporting to an image file sequence or a video file. Chosing one or the other drastically changes the following decisions, so that part comes first. In the example here on the left, the user has selected the "Image" output type, which would disappear the two Audio and Video encoding panels and reveal Blender's existing layout for image encoding, which is fine. The Frameserver setting belongs in a section of its own.

2. Video Presets Useful, editable video presets would be fantastic! The ones shown here should not be taken too seriously; I only show them to demonstrate what some useful built-in presets might look like- descriptive and platform-specific. Blender could come packaged with lots of built-in presets, and it would be easy for the user to delete all but the relevant ones from his/her starup file. Presets could perhaps even exist as datablocks of a sort, allowing the user to import a preset from one file to another. Presets exist in the output panel, allowing the user to see, at a glance, what settings they're using without opening the other two panels.

3. Containers and Codecs The user's choice of container format dictates the available codecs to follow, so that comes first in this panel. This menu lists the full name of each container plus the file extension associated with it. Depending on what container the user selects, incompatible codecs are greyed out, preventing any settings that might cause errors or produce bad files. The availability of BW/RGB/RGBA channels depends on what codec is being used, so those settings come immediately after.

4. Compression Like any good UI proposal, this one comes disguised with a feature request: an option for fixed-quality video compression. This would be useful for cases where a consistent bitrate is less important than consistent quality, and I think a lot of users would appreciate it. I will leave the specific layout of the more advanced settings here as an excercise for someone smarter than me, but would like to recommend that these settings be more codec-sensitive; disabling options that aren't relevant to the selected codec, and enabling ones that are. Lossless codecs, for instance, would not have any available options for setting bitrates. The "Autosplit Output" checkbox has been moved to the output panel, where I think it makes more sense.

5. Audio Encoding As with video codecs, audio codecs that are incompatible with the selected container would be greyed out. The existing bitrate parameter has been replaced with a menu of standard rates. Audio encoding is enabled/disabled by the checkbox at the top of the panel, allowing the user to see at a glance whether they're exporting audio.

Talk Section

Rocketman

Thank you for reading this far into my rant about this rather minor area in Blender's workflow. I realize that this proposal is the laziest form of contribution; by taking care of the easiest stage of development, I'm hoping that someone will come along and do the hard part. In this proposal I also expect to have committed a few errors; perhaps I've even fundamentally misunderstood how video exporting works! In spite of this, I hope everyone will agree that Blender's existing video output UI is embarrassing, and deserves the attention of developers. If you are a contributor and have anything to add, please do so below this line or in the discussion section. Thanks!

-Rocketman

Nazo

I also think there are the need to fix this mess. but I want to select a format by use-cases as a option. like this (incomplete):

• Web Authoring -> PNG, JPG, H.264, WebM, Flash Video, Youtube, Vimeo
• Disc Authoring -> DVD, BD
• Print Authoring -> PNG, JPG, TIFF
• Cinema Authoring -> JPEG2000, DCP
• Device Authoring -> iPhone, Android, Android 2.x, ATSC TV, DVB-T TV, ISDB-T TV, etc...
• Software Player Authoring -> WMP, QT, Totem
• NLE/Encoding Intermediate Format -> Targa, PNG, FFv1, HuffYUV, DNxHD, ProRes
• Colorgrading Intermediate Format -> EXR, DPX, Cineon
• Compositing Intermediate Format -> MultiLayer EXR, EXR

--Nazo 10:48, 23 August 2014 (UTC)

Nazo, could those could be put as the column headers for the appropriate menu, similar to the modifiers drop down or where Image and Movie are here:

Blakenator

IMO, that would save the use of extra widgets where there already are too many and accomplish the same thing.

--Blakenator 8:24 AM, September 3 2014 CDT (GMT -6:00)

Sobotka

Nice to see some discussion about this.

I'd start by asking "Who is this for?" and I don't mean the typical silly response "Everyone of course!" I would ask for some hard and realistic targets that can be designed for. If we look at the Blender about page, I see:

Blender is well suited to individuals and small studios

Why is this important? Because some of the details you are investigating have a direct impact on a small studio. In short, having a clear audience allows us to evaluate a design with context that would otherwise end up random opinion and anecdote.

So what might be mandatory for a small studio? Smaller (and larger) studios have very specific needs, in particular with regard to taking a project to broadcast or shipping to a client. These needs of course overlap with an independent artist trying to push their work for broadcast or to a prospective client. That said, some of the needs of the small studio are unique and cannot be negotiated from a design that oversimplifies excessively for an individual, while an individual can still harness a design that targets a small studio.

Some of these needs might include:

• Fine grained and accurate control over 601, 709, 240M, color encodes with toggles and assertions that the encode is correct.
• Fine grained and accurate control over the reference standard broadcast range versus full range or other edge cases.
• Control over the reference standard baseline codecs. This would be a hot point of contention, but if anything, this post highlights that there are simply too many options in that list. A design with context should focus on a specific audience and work to address that audience's needs. Codecs worth considering are DNxHD, Cineform, ProRes, h264 (dailies).
  • Due to cultural lineage and importance, include at least one reference standard baseline codec that is patent and royalty unencumbered. Blender is Libre software, and as such should aim to respect that lineage while integrating the above needs.
• Control over the look baked into the footage via LUTs or other transforms. Applicable to dailies or trim passes for broadcast outs.
• Control over the format wrappers with assertions of correct atoms being set for above. MOV, MXF, etc.

In this light, and this is just a small subset of contextual needs, I'd encourage the evaluation of the interface in a "work backwards" sort of manner.

The existing interface is a byproduct of a design accumulating over time without a focus on audience and context. To attempt and design a new user interface panel without such attention to audience and context would likely end up precisely where it began. -- Sobotka 18:26, 7 January 2015 (UTC)

MikePan

I am 100% for this proposal. The current encoding panel is very much a nightmare to use. Some point worth mentioning:

• The propose UI makes it look like Audio is not affected by the Container setting, which is misleading. Suggest putting container under the Output type header so that audio and video each gets a section. (Source)
• I am not sure if FFMPEG is doing all the encoding in the backend, it might be good to communicate to the user which library is doing the encoding. On a Mac, one can choose to let FFMPEG do the encoding, or using the quicktime library for mov containers.
• Encoding bitrate should not be presented in bits. In this day and age, kilobits should be the minimal. Also, agree that 10Mb/s is too small for HD quality encoding.
• Presets as proposed is perfect. I would argue we should extend it to the Still Images output as well. It is common to want to switch between low quality JPG to multilayer EXR during production.

-- mikepan