Output mp4 from VSE optimized for web (specifically YouTube)

Support Compositing and Post Processing
1

I’ve started a Blender tutorial site and recently posted my first video, hosted on YouTube. The video is simply a series of images and text that fade in/out and crossfade. (A lot of Alpha Over) The main content of the video is about 1/3 the width of 16:9, so all the strips (except in the intro and outro) sit on top of a background image that is full size.

I rendered out the final video file with the following settings:
http://thezedlab.com/wp-content/uploads/VideoOutSetting.png
These are as close to what YouTube reccommends as I can get in Blender. The resolution is 1920x1080, framerate is 24fps.

There are some playback issues that appear on YouTube but not in the file locally on my computer. Here’s the vid on YouTube:

https://youtu.be/MvB2wggWcrU

You can see the background flicker and some other artifacts. (The wonkiness where the wireframe image cross fades into the final render at the beginning occurs in the video file on my computer as well, but nothing else.)

So, after all that, my question is: Is there a better way to optimize video ouptut from Blender, specifically for upload to YouTube? Or, should I get QuickTime Pro or FFMpeg or something similar to render out final video files?

Somewhat related, does it make any sense to render out an image sequence from VSE, then render that image sequence to video (when no actual animation from Blender is being rendered)? For example, if in VSE you took two still images and say, faded in from black, cross faded them, than faded out to black, would it make any difference to the encoding if you then rendered that straight to a video file or rendered that to an image sequence then rendered that image sequence to a video file? Seems redundant.

Anyway, any advice would be greatly appreciated.

2

Hi,
#1. flickering: it’s constant and it is caused by the gop size.
#2. artifacts: are due to (re)compression

Blender does use ffmpeg to read and write video files but the version it uses is not the standard ffmpeg one, i.e. the one you can get from repos. Also, Blender hides most of the dozens of rendering options that are available in ffmpeg through the CLI and these give more control over the encoding process.

The good news is that there are several workarounds, if the quality is not satisfactory and you want to render straight from Blender, then I’d suggest to use a bitrate which is at least twice as high compared to the (pretty conservative) one recommended by YouTube. Considering that 5mbps is the minimum bitrate for SD video, 8 mbps is very conservative for fullHD video, which has 5 times more resolution. So set the video bitrate to 16mbps or even more, and give it another go. Adding some dithering will probably help in your case as you’ve got lots of fades with gradients where banding is painfully obvious.

Second, you can render out straight from Blender either using a lossless codec (say HuffyUV) or a very high bitrate one (say DNxHD). You can then use ffmpeg to compress the resulting file using one or (preferably) two passes. This is the route I normally take as it provides absolute control of the encoding. Note that it is also possible to render out a high bitrate file that is more down to earth compared to lossless or DNxHD (i.e. between 20 and 30mbps) and either try ffmpeg to encode it yourself or upload it to YouTube and see what the resulting encoding is.

Finally, rendering image sequences is the way to go, there are numerous advantages for doing so. You can then import the image sequences into the VSE and create a video file which can then be further encoded for delivery using any of the options outlined above.

3

Thanks for the reply. You mention the flickering was due to the GOP size, which I set to 12 as recommended by YT (1/2 framerate). I have in the past, for videos not intended for uploading, set the GOP to 1. YT recommends variable GOP, which is not an option in Blender. I wonder if setting it to 1 would then cause the re-compression on YT’s side to use variable GOP?

Not sure what you mean about “fades with gradients”. All the fades are either by adding cross effect strips between image strips (the magenta ones between the two strips on the same channel) or keyframing the opacity of a color strip on a channel above another. But I suppose if banding creeps in regardless, dithering will help.

I can try upping the bitrate. However my CPU power and bandwidth are not that great. The video as it is now took about 2 1/2 hours to render out the mp4 (from an image sequence of PNG’s created from the original sequence) and about 1/2 hour to upload.

As I have already rendered out all the frames as PNGs, it might be better to go right to ffmpeg and encode the image sequence (which I assume can be done, I’ll have to read up on ffmpeg). That way I can skip rendering out in a lossless codec (which no doubt will take even longer).

Thanks again, I’m gonna have to experiment to find the most efficient workflow to produce the best quality results (I should probably at least buy a new computer :))

4

I am guessing if raising up the minimum bitrate increases the video quality…
Great topic anyway, good knowing about gop and flickering.

5

Also Blender tends to have very poor first frames upon rendering out to compressed codec (not image seq). So try to delay the first image if possible or make a fade from black. I think this is due to the single pass encoding that Blender’s ffmpeg.

6

You are right. In a my animated project I rendered (or simply copy and past) four or five times the first frame keeping in account this little issue.

7

Please allow me to correct mysellf (slaps face):
flickering is NOT related to GOP size, NOT in this case anyway and certainly NOT in this context with the specific container/codec combo!
Terribly sorry about misinforming you :frowning:

Background: I’ve been doing a lot of webm encoding for the past two years (videotutorials) and the signle most infuriating setting was/is the GOP size. Setting it to 1 (i.e. every frame is a keyframe) results in constant (per second) flickering which makes the video hard to watch. Through trial and error (due to lack of documentation proper) I’ve settled for values between 500 and 1000. They make the video hard to index/navigate but make the flickering less noticable (i.e. every 10 secods or more).

The truth is that the youtube settings mentioned puzzled me. In my experience, using a low bitrate and a small gop value (less than the fps value) would be a recipe for disaster with a webm container. So I tried these settings with an avi container. I actually encoded a lossless videotutorial using the following settings:


As you see, I doubled the bitrate to 12mbps and increased the minimum to 6mbps and left the gop size at the default value.
Then I uploaded the video to youtube and checked the results. Contrary to expectations, there was NO flickering whatsoever! :0
The image was very stable, it’s quality was very high (despite youtube recompression). Ain’t this a kick in the head or what? :wink:

Anywayz, I used mediainfo to check the actual encoding settings used by Blender’s ffmpeg version. Another suprise:

General
Complete name                            : /video_test.avi
Format                                   : AVI
Format/Info                              : Audio Video Interleave
File size                                : 19.0 MiB
Duration                                 : 1mn 57s
Overall bit rate                         : 1 353 Kbps
Writing application                      : Lavf54.29.104

Video
ID                                       : 0
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : [email protected]
Format settings, CABAC                   : No
Format settings, ReFrames                : 4 frames
Codec ID                                 : H264
Duration                                 : 1mn 57s
Bit rate                                 : <b>1 147 Kbps</b>
Nominal bit rate                         : 12.0 Mbps
Width                                    : 1 280 pixels
Height                                   : 720 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Variable
Frame rate                               : 25.000 fps
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 0.050
Stream size                              : 16.1 MiB (85%)
Writing library                          : x264 core 118
Encoding settings                        : cabac=0 / ref=2 / deblock=1:0:0 / analyse=0x3:0x113 / me=dia / subme=6 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / <b>open_gop=1</b> / weightp=2 / <b>keyint=15 / keyint_min=8</b> / scenecut=40 / intra_refresh=0 / rc_lookahead=15 / rc=cbr / mbtree=1 / bitrate=12000 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / vbv_maxrate=12000 / vbv_bufsize=1835 / nal_hrd=none / ip_ratio=1.40 / aq=1:1.00

Audio
ID                                       : 1
Format                                   : AAC
Format/Info                              : Advanced Audio Codec
Format profile                           : LC
Codec ID                                 : FF
Duration                                 : 1mn 57s
Bit rate                                 : 256 Kbps
Channel(s)                               : 2 channels
Channel positions                        : Front: L R
Sampling rate                            : 44.1 KHz
Compression mode                         : Lossy
Stream size                              : 2.69 MiB (14%)
Alignment                                : Split accross interleaves
Interleave, duration                     : 23 ms (0.58 video frame)

As you see, open gop is automatically set to 1, the GOP size is indeed set to 15 but it seems that a value of 8 frames is also automatically set as a minimum GOP size by Blender. Unfortunately, these options are not directly accessible from the UI --if they are accessible at all (need to check that out -for instance it would be great if we could change the qmin & qmax values from the UI but oh well).
Consequently, with an AVI container (haven’t checked with matroska or mp4), the recommended youtube settings are very conservative regarding the bitrate but NOT regarding the GOP size. I was dead wrong there.

The obvious solution would be to double or even triple the bitrate and then upload your video to youtube. This is because it will be re-compressed and you need to take that into account. For instance, I downloaded the video which I uploaded and checked the encoding info:

General
Complete name                            : video_test.mp4
Format                                   : MPEG-4
Format profile                           : Base Media / Version 2
Codec ID                                 : mp42
File size                                : 11.0 MiB
Duration                                 : 1mn 58s
Overall bit rate mode                    : Variable
Overall bit rate                         : 780 Kbps
Encoded date                             : UTC 2013-04-15 20:54:14
Tagged date                              : UTC 2013-04-15 20:54:14
gsst                                     : 0
gstd                                     : 118141
gssd                                     : B4A7D0BE1HH1366147749616561
gshh                                     : r2---sn-nv47ene7.c.youtube.com

Video
ID                                       : 1
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : [email protected]
Format settings, CABAC                   : Yes
Format settings, ReFrames                : 1 frame
Format settings, GOP                     : M=1, N=60
Codec ID                                 : avc1
Codec ID/Info                            : Advanced Video Coding
Duration                                 : 1mn 58s
Bit rate                                 : <b>586 Kbps</b>
Maximum bit rate                         : 4 604 Kbps
Width                                    : 1 280 pixels
Height                                   : 720 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 25.000 fps
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 0.025
Stream size                              : 8.24 MiB (75%)
Tagged date                              : UTC 2013-04-15 20:54:17

Audio
ID                                       : 2
Format                                   : AAC
Format/Info                              : Advanced Audio Codec
Format profile                           : LC
Codec ID                                 : 40
Duration                                 : 1mn 58s
Bit rate mode                            : Variable
Bit rate                                 : 192 Kbps
Maximum bit rate                         : 202 Kbps
Channel(s)                               : 2 channels
Channel positions                        : Front: L R
Sampling rate                            : 44.1 KHz
Compression mode                         : Lossy
Stream size                              : 2.70 MiB (25%)
Title                                    : IsoMedia File Produced by Google, 5-11-2011
Encoded date                             : UTC 2013-04-15 20:54:16
Tagged date                              : UTC 2013-04-15 20:54:17

Their encoder put it into an mp4 container with an h.264 codec but the bitrate dropped considerably compared to the originally uploaded one (1.1 mbps vs 0.586 mbps).

Again, sincere apologies for providing incorrect info on this one.

Hope this helps.

8

please see my post above & ignore my comments on flickering and gop size in this case; they don’t apply

Not sure what you mean about “fades with gradients”. All the fades are either by adding cross effect strips between image strips (the magenta ones between the two strips on the same channel) or keyframing the opacity of a color strip on a channel above another. But I suppose if banding creeps in regardless, dithering will help.

Dithering should certainly help if the bitrate is low. But I suggest you double or triple the bitrate to eliminate any need for dithering. You’ll need to experiment.

I can try upping the bitrate. However my CPU power and bandwidth are not that great. The video as it is now took about 2 1/2 hours to render out the mp4 (from an image sequence of PNG’s created from the original sequence) and about 1/2 hour to upload.

There is no way around that though. Once you’ve rendered stills, creating the video file should go pretty fast.
Btw, this is exactly what I did with the video I tested: I imported a rendered lossless HuffyUV video into the VSE and created the video file described in my former post. Using an image sequence would give the same results.

As I have already rendered out all the frames as PNGs, it might be better to go right to ffmpeg and encode the image sequence (which I assume can be done, I’ll have to read up on ffmpeg). That way I can skip rendering out in a lossless codec (which no doubt will take even longer).

yep, that’s also possible, usig two-pass encoding is highly recommended.

Thanks again, I’m gonna have to experiment to find the most efficient workflow to produce the best quality results (I should probably at least buy a new computer :))

if it can render out one frame per second in fullHD then I’d consider it to be a meaty machine! :slight_smile:

9

So what causes the flickering?

10

So what causes the flickering?

From what I gather a low GOP value causes the flickering. Which maskes sense, as the GOP determines the distance between keyframes in the encoding. If every frame (or every other frame, etc.) is a keyframe, the encoder is constantly rechecking the data, rather than interpolating across many frames and ignoring what doesn’t change. I imagine, since some areas of the frame are changing and each frame is a keyframe, the encoder is constantly “resetting”. That’s my understanding of it, though I’m a bit spotty on the particulars.

@blendercomp, many thanks for all the valuable info you’ve provided. When I have time over the next few days I’m going to do some experimenting based on the advice given.

And thanks to 3pointEdit for the tip about first frames, I was not aware of that issue.

11

Correction: as blendercomp clearly states above, the flickering in this case is not caused by the GOP. This is borne out by his test using a GOP size of 15 and seeing no flickering occur. With my video it all comes down to a bitrate that is too low (especially for full HD). He used a bitrate higher than I did (12000 vs 8000) and his video was of a smaller resolution (720, I believe).

But, what I gather from the comments is that flickering can be related to GOP in some circumstances (depending on container and codec, I imagine?), in which cases I think my previous comments hold true.

Just wanted to correct myself, this was bothering me at work today. (My day job can be very boring :))

12

@3point: I can’t give an offhand algorithmic account of the issue atm but the empirical test I did leads to the conclusion that gop size is unrelated to flickering in THIS context (i.e. the specific container/codec combo). I know for a fact that using a low gop value with another container/codec combo would lead to flickering if the bitrate is less than 3mbps. I’m also thinking that Google wouldn’t give such compression specifications if small gop sizes were poor for h.264, would they?
The bitrates specs they give are very low IMHO but hey, this is internet video we’re talking about here and it will always be less optimal compared to delivery say in optical media (or it will take forever to download and mpeg 4 was designed to address delivery problems).