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.

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.

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: http://www.fnordware.com/WebM/. I got an average of 0.3fps at 4K resolution on a Xeon 1240v2.

Some notable comparisons:

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

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

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.

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.

ENCODING:

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?)

ANALYSIS:

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.

PSYCHOVISUAL

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!

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)

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

@salvador

...SD of course.

The pretentiousness is strong with this one.

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

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 = $$

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.

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

Cheers