Personal View site logo
Make sure to join PV Telegram channel! Perfect to keep up with community on your smartphone.
Best render settings for Youtube
  • 23 Replies sorted by
  • Doesn't YouTube accept raw now? ;-) Some guys were up-scaling 2k--> 4k and noticed that it looked better than the 2k uploaded. Seems like the encoding server has a mind of its own.

    Considering how quickly tech is changing- and that YouTube keeps your original files somewhere upload the largest and least compressed you can. In a few years H265 will be the standard anyway.

  • and that YouTube keeps your original files somewhere upload the largest and least compressed you can. In a few years H265 will be the standard anyway.

    I am not sure they keep most videos.

    In reality if you regularly upload videos it is little reason to upload huge files.

  • Whatever they use to encode, it isn't always the same. Years ago they went back and re-encoded a lot of files and some of these were upgraded from SD to HD if the source file was 720p or higher. But maybe that was a onetime thing, who knows? You can't go wrong with using a higher bitrate, within reason.

  • I used to render H264 in Premiere for direct upload to YT. After doing some testing, it looks to me that rendering to Quicktime/DNXHD and then encoding using Handbrake X264 gets you better quality.

  • Did some visual subjective research about encoding for Youtube a few weeks ago. All of it can be read at my blog, but for as it is in Dutch, I'll try to summarize some of my findings.

    • Most of the times, x264 encoder (used by Handbrake or ffMpeg) gives a visually more pleasant result on Youtube. It has more options to play with, but is also a bit harder to learn. It's a lot faster than Adobe Media Encoder's Mainconcept H.264 codec as well.

    • Youtube's maximum output bitrate never exceeds 50Mbps (try it yourself by watching any video on Youtube and click 'stats for nerds'). So most of the times, limiting your input bitrate at this rate will be a save bet for retaining the most quality of your upload.

    • Youtube is betting on Google's VP9 codec (and later VP10, which is currently in development), so I don't think H.265 will become standard on Youtube.

    • VP9 should be more efficient, so at Youtube's 50Mbps output, you should retain a lot more quality at the same resolution.

    • Encoding VP9 on current-gen hardware is terribly slow. You can download a plugin for Adobe over here: I got an average of 0.3fps at 4K resolution on a Xeon 1240v2.

    Some notable comparisons:

    x264 Comparison Mainconcept H.264 wins in retaining small details on Youtube.

    x264 Smooth rendering Youtube fail Couldn't get a smooth ball on Youtube with the x264 Encoder.

    So with this research I developed a tool which should give you the best encoding settings in any condition. Watch this topic for updates.

  • @jondezwaan

    Btw, youtube using VP9 and such in their HTML5 player frequently cause big difference in power consumption and processor load in notebooks and tablets. As H.264 plays in hardware.

  • @jondezwaan a number of people have done such tests and come up with different answers--the reason is twofold, one is that youtube doesn't always use the same encoding system, and second is the question of futureproofing--, that is, if they re-encode the video at a later date, the results may be different. No one knows, AFAICT, whether H265 will futureproof vid in the way that H264 did some years ago. So the advice or tests that are online may or may not be right. You need to also try jpeg and custom gop combinations, and remember there's different flavors of 24p.

  • Yeah, I understand my research isn't destined for a long lifespan, Youtube's current shift towards VP9 already changes numerous things, but that's with everything related to technology. However it's based on Youtube's H.264 behavior and my results are definitely not scientifically justified. I did it by visual observation and trying to predict Youtube's current H.264 encoding algorithm.

    I did upload a decent amount of video's for observation, divided in 4 categories:

    I don't know every detail about encoding (yet, I hope), and I appreciate every bit of shared knowledge, so what do you mean by 'trying JPEG'? As for custom GOP, Media Encoder only let's you set a Keyframe Distance, and both Youtube and Vimeo both advice a closed GOP, could you tell me why I should try a higher Keyframe distance than 1? As far as I know an All-Intra encoded video should give better retention in detail and movement, especially when it's re-encoded by Youtube's garbage encoding algorithm.

    But then again I'm definitely not an expert and appreciate every little bit of help in developing a useful tool.


    P.S. I'll try to add more framerates in the next update; 23.976, 29.97 and 50.

  • YouTube recompresses everything that you upload. So it doesn't particularly matter what kind of compression you use in the file you upload. What matters is what the video you upload decodes to. The decoded version of your upload is the input to YouTube's compressor. The higher the quality of the decoded upload, the better.

    Also, it helps to upload video without too much motion or noise, because YouTube's compression will be starved for bits if there is a lot of motion or noise to encode. YouTube doesn't allocate enough bit rate for all conditions. If you really want to optimize the quality of videos in YouTube, minimizing noise is where you're going to have the greatest effect.

    And, by the way, their encoding algorithm is not garbage. It's highly optimized. The problem is insufficient allocation of bits, not the algorithm.

  • @jondezwaan sorry I meant keyframe, some people have reported very good results with JPEG motion in avi container, but that was a few years back.

    @balazer it seems clear that every now and then the re-encode the source file. So in these cases it can make a difference which codec you use, because when they re-encode, they look for certain files that fit a profile, and they skip the ones that don't look promising.

  • I started trying to discover a fitting algorithm for Handbrake, but I think I need some help.

    First my thoughts:

    When you have no limitations in terms of filesize, bitrate etc. The Handbrake guide seems to recommend using the CRF slider, (20 for HD footage). Downside of this, is that my tool can't calculate filesize, encoding duration and uploadtime. But we have to keep in mind we're uploading for Youtube (or Vimeo) and they do have there limitations, so wouldn't it be nonsense to upload a RF 20 file and finding out you have bitrate exceeding 50mbps? (which was previously the recommended bitrate according to Youtube for High Quality uploads).

    So my thoughts on having a maximum quality default starting point for Youtube without any other limitation would be:

    Average bitrate: 50000 kbps (some say 16000kbps is sufficient for HD, but in my experience 50000 maintains way more detail when being re-encoded by Youtube, see attached GIF) 2-pass encode.


    Reference 1 (All-intra) B-Frame 0 (All-intra) CABAC: ON (Youtube recommends it, so why turn it off and use CAVLC instead?) 8x8 transform: ON (No reason to turn it off, I guess) Weighted P: off (Not necessary when encoding all-intra, right?)


    My thought of the starting point would be setting the analysis value's to lowest possible, because we're encoding to an all-intra video and my guess is it's not necessary to do slow analysis when there's no need for motion estimation.


    As we're encoding to an high bitrate video, my guess would be to set aq-strength to 0, because we've sufficient bits to maintain high quality, and turn No-DCT-decimate to ON, because by default we would like to maintain fine details and again have sufficient bits.

    So with this starting point the main goal of the algorithm is to keep the bitrate as high as possible, because this is the leading quality factor.

    When doubling the reference frames and b-frames (2 and 2), in my experiments, the compression increases with an average of 2-5%. Setting the ref and b frames to the maximum recommended sane values by handbrake (6 and 5) and turning weighted P-frames on, the compression increases even further, with an average of 5-8%; If the bitrate can stay within the recommended values, these are the only encoding settings to touch.

    When the calculated bitrate drops below the recommended HD value of 8mbps. I think we should involve better analysis and psychovisual settings, but I haven't come to that part yet.

    I hope this sounds plausible and if anyone can look at this and give some feedback at these thoughts, please do!

    Animated GIF

    As you can see Youtube now re-encodes uploads twice, first a fast pass to H.264 and after some time it will be converted to VP9, which unfortunately degrades the quality even more, but still 50000 kbps retains more detail compared to the 16000kbps)

  • Is there any point in exporting footage with anything more than 4:2:0 color for youtube? Can it display 4:2:2 or 4:4:4 properly?

  • YouTube is 4:2:0 8-bit using Rec.709 level ranges. If you upload anything else it will just get converted to that.

  • My ideology is that if a video doesn't look good and/or keeps my attention in SD (480p), then there is no point on watching it on HD.

    As far as the best settings for YouTube, I'll say ffmpeg CRF 22 to 25. SD of course.

  • @salvador

    ...SD of course.

    The pretentiousness is strong with this one.

  • joethepro: You can tell me directly that you believe I am pretentious. It's OK. No need to direct your comment to the online pals looking for support.

    Back on topic. Uploading good quality SD to YouTube, causes the processing time to be almost null, so the videos are available almost immediately after uploading them.

  • @salvador Lighten up, Im just teasing. Anyone who says to upload to YouTube in "SD of course" in 2016 is just trying to stir the pot. No one will care if it takes twice as long for your HD video to process (whats a few minutes difference going to affect?) if it looks vastly sharper. People actually care about resolution now that UHD is becoming the norm. This is like saying that there is no need for color in your film since you should be able to enjoy it in black and white. Yes, of course, but everyone wants to see pretty colors.

  • I prefer to upload UHD to Youtube from my G7 and Note 4, and for quick stuff I avoid re-encoding. Avidemux can do basic splicing and editing without reencoding very well. Processing time doesn't matter, as stuff will show up soon anyway. Why the rush? Also, ugh, I hate looking at SD on Youtube. Or anywhere else for that matter. 720p should be a minimum these days. Here's the official page for the recommended specs:

  • My only perspective here is corporate clients, who care about reviewing the event that just ended as soon as possible on the link I sent them. So in this particular case (corporate clients), processing time for distribution is of the outmost importance, and if I can do it by sending video that looks OK even in full screen mode (at 480p), the client will be pleased which = $$

  • Yeah, but the way that YouTube works is that it always processes a 480p copy first anyway, so you'll still be able to give out the link early. Uploading 720p shouldn't take that much longer to get a 480p copy posted.

  • Anyone know why videos always have the shadows lifted when processed by YouTube? This annoys the shit out of me, and I can't seem to find a setting in Adobe CC that will give me a consistent match, i.e. the YoiuTube video looks the same as the video file played straight off the hard drive. I render using the H265 YouTube or HD 1080 preset. If anyone knows which setting retains color/luminance fidelity please share. Cheers.

  • There are two possibilities: the encoding is not correct, or the playback is not correct.

    YouTube will correctly process uploads using either of two different standards for level ranges in Y'CbCr video. One is Rec.601/709 ranges, with a 16-235 range in the Y' channel, and 16-240 in the Cb and Cr channels. The other is h.264 video with the video_full_range_flag set, a Y' channel range of 0-255, and Cb and Cr channel ranges of 1-255. The video_full_range_flag should be set if and only if your video is encoded with full range levels.

    Any full range video you upload will be converted to Rec.601/709 ranges. All of the video that YouTube delivers for playback is meant to be played using 601/709 ranges.

    The other possibility is that the playback is mapping levels incorrectly. This aspect is actually pretty complicated, because there is the Flash player and the HTML player, and it can depend on your browser, your video card drivers, and on the driver settings. (and of course there are lots of other YouTube video players like phones, tablets, set-top boxes, TVs, and dongles) My Nvidia control panel, for example has a video color setting called "Dynamic range" which can be set to Full (0-255) or Limited (16-235). It needs to be set to Full (0-255) to display colors correctly.

    You can check for playback problems with this video:

    I've attached an image of a proper rendering and an improper rendering. In the proper rendering, black and white are true black and white. At the bottom under the red bar there are three thin vertical bars: -4%, 0%, and 4% brightness. The -4% and 0% bars should both appear as fully black. In the improper rendering, the -4% bar is black and the 0% bar is slightly brighter.

    Incidentally, there is another playback problem that a lot of YouTube players are guilty of: using the Rec.601 Y'CbCr to RGB matrix instead of the Rec.709 Y'CbCr to RGB matrix. I've attached an image of that as well.

    I can try to help with encoding settings for Adobe Premiere, but let's exclude a playback problem first.

    Color bars proper.jpg
    1920 x 1080 - 52K
    Color bars improper.jpg
    1920 x 1080 - 51K
    Color bars improper matrix.jpg
    1920 x 1080 - 51K
    Color bars improper levels and matrix.jpg
    1920 x 1080 - 50K
  • @balazer

    Thank you kindly for the info and tools to identify the source of the problem. It's past midnight here so I'll only delve into it when I get up. I'll PM you to minimize clutter - we can later decide what to post that would be pertinent to the thread.