Can you explain what is purpose of setting max_b_frames and overall keyframe interval to these values? This should be included in commit message.
I once played with these values but I don't remember they would have any significant effect on output. So perhaps there was but I just tested this wrong.

Imo, the main thing here is when users are using the "Video Editing" profile, it would be more user-friendly to have video+audio render settings as defaults. Anyway, it just a thought, and I'll leave it up to you guys from here.

It took me a moment to understand what this is doing from the patch description. First I thought it adds a new preset. (I generally try to understand the changes from the description first, before looking at the code).
Better to clearly state what this does: It modifies the "Video Editing" template so that YouTube compatible encoding settings are the default (right?). It doesn't really add anything, just sets a different default.

Are these settings available as a preset? If they are useful, they should be. Rather than setting a bunch of settings to be useful by default, we should use a preset by default.

Adding Sybren as reviewer, since he knows this stuff well and may have a better idea of what is reasonable and what not.

@Julian Eisel (Severin) It's just this profile: https://developer.blender.org/diffusion/B/browse/master/release/scripts/presets/ffmpeg/h264_in_MP4.py but used for the Video Editing profile. Maybe it can be run directly from Video Editing workspace template?

If you want to offer a video-export friendly profile for users when they start Blender in the Video Editing profile, let me know and I'll do the corrections to make the profile exactly like the h264 profile.

I'll leave the decision which settings are best for default to others (e.g. Sybren). But I do think that whatever is the default should match a preset. Ideally by just activating a preset, not by setting the values manually (that can easily go out of sync).

If the goal is to make Youtube compatible encoding settings the default, doesn't it make sense to use Youtube's recommended encoding settings?

In D7916#248195, @Julian Eisel (Severin) wrote:

I'll leave the decision which settings are best for default to others (e.g. Sybren). But I do think that whatever is the default should match a preset. Ideally by just activating a preset, not by setting the values manually (that can easily go out of sync).

Thanks for feedback, I mostly wanted to know if this is OK from UI point of view, I agree with aim of this change.

I agree with proposed approach - just activate the preset. H264 in mp4 preset does not set audio for output. So this needs to be set in app template if there is reason why it is not part of preset. That is question for @Sybren A. Stüvel (sybren) if it needs to be that way or we should add audio to video preset(s).

As for the audio settings, I think it is a good idea to enable audio by default in the Video Editing . AAC is a decent enough codec, but 384kbit is overkill. 192kbit is probably fine, 128kbit could also be a suitable default.

Why is YouTube so special that Blender needs to change its defaults for it? Why not use the Vimeo or PeerTube recommendations?

The settings themselves (REALTIME preset, so large output file, and 384kbit AAC audio) seem more like suitable for a studio setting than to produce a file that needs to be uploaded (and thus not super large).

I had a go at updating the template P1874 , however python_file_run is causing a context error - is this an 2.92 introduced bug?
Also I couldn't find a good way to locate the path of the template. So I need help with these things.

I've added presetting SMPTE as default Animation Timeline, since this is an industry standard.

Discussed best way of loading preset with @Campbell Barton (campbellbarton) and came to following approach:

render = bpy.context.scene.render
render.image_settings.file_format = 'FFMPEG'

preset = "h264_in_MP4"
filename = bpy.utils.preset_find(preset, preset_path="ffmpeg")
if filename:
    bpy.utils.execfile(filename)
else:
    print("Preset %r not found" % preset)
    
render.ffmpeg.audio_codec = "AAC"
render.ffmpeg.audio_bitrate = 384

In D7916#250677, @Sybren A. Stüvel (sybren) wrote:

As for the audio settings, I think it is a good idea to enable audio by default in the Video Editing . AAC is a decent enough codec, but 384kbit is overkill. 192kbit is probably fine, 128kbit could also be a suitable default.

128 kbit is good enough for speech, but terrible for music. 192kbit is absolute minimum for general purpose IMO. I would argue that audio quality is cheap in terms of filesize so it seems reasonable to go for higher values here. I would consider 256kbit to be OK for most cases.

Why is YouTube so special that Blender needs to change its defaults for it? Why not use the Vimeo or PeerTube recommendations?

Agree here. I don't think these defaults should aim at being in line with any video platform recommendations unless Blender would have special preset for that. I would need to check if such presets are even allowed.

@Sybren A. Stüvel (sybren) @Richard Antalik (ISS) @Campbell Barton (campbellbarton) @Julian Eisel (Severin) Bottom line is, the built-in application template for a VSE should not export to an image sequence without sound... I've tried to update this patch continuously according to the various demands being raised, but at this point and at this hour, I think one of you guys should commandeer this patch, and commit whatever code you think will solve the original problem, so I'm abandoning it.

@Peter Fog (tintwotin) we are aware this is a reasonable change, screenshots of complaints on social media isn't especially helpful.

In D7916#266701, @Sybren A. Stüvel (sybren) wrote:

I don't understand some of the review notes.

@Campbell Barton (campbellbarton) wrote:

Avoid using the context in versioning code, loop over bpy.data.scenes instead.

What is "versioning code" in this context? This code is called from the load_factory_startup_post handler.

Yes, that's what I was referring to, these should be split into functions (named that it's clear they are for versioning).
Done.

As far as I can see it's straightforward to update the patch to meet requirements.

• Split FFMPEG startup updating logic into a function, only run it when FFMPEG build option is enabled.
• Use script.python_file_run operator to run the preset, overriding the "scene" context member.

Tested this and as far as I can see it's working as intended: P2320

Removed Sybren as he's not available to review, his concerns regarding script execution have been addressed.