2nd pass is required most of the time if you need to control total file size. Sometimes it is usable if you have very high detailed scenes that can cause very high bitrate rise (and use suitable VBR setting).

Thanks for the responses! I just figured since YouTube and Vimeo have 8mbit and 5mbit rates respectively, I figured 10mbit would be "very high" in terms of what a client would need. However, it's good to know with motion it could be an issue.

Like Vitaliy has said before, a 2 pass encoding doesn't make any sense unless you are space limited. A 2 pass encode is mostly about finding the best constant quality that will fit a certain file size. If you are not limited, then all the better because it's YOU that choose the quality.

If you are worried about quality, what you have to do is find the quality (better yet, the Constant Rate Factor) that you are satisfied with, and then do your exports at that level. Depending on content, sometimes they will be big, sometimes they will be small, but one thing is for sure, quality will always be the same...

I have occasionally had VBR files completely mucked up by both youtube and vimeo on static scenes or titles. Of course, you can always reupload it if it doesn't look good. There is always a chance that the video will be reencoded at a later date.

@DrDave : The thing is : the file looks bad after being encoded on my computer, i didn't upload it on any streaming platform ;)

@balazer : Thanks, I'll try these settings and keep you informed. What software/GUI ( if avisynth based ?) are you using ? Right now MeGUI is exporting crap, more specifically "ghost" files, I know where they should be located but there're invisible and can't be opened using search function.

@krotal "MeGUI is exporting crap"

I use MeGUI for all my x264 encoding. It integrates with Donald Graft's MPEG decoders and AVIsynth very well (so it can take Cineform input). Using x264, I choose "High Profile" "Unrestricted" "Single Pass Constant Quality" with a quality of around 25-30 for YouTube uploading, and 20-22 for serious work. I use a Hexagon for motion estimation. MeGUI has never failed me.

A Q16 export should be transparent for most people's eyes. I do most of mine at Q18 and I've never spotted any issues. I think you are right that if the issue was with the extreme grading, you should see it in AE in the previewer, before exporting but... just to be sure it's not that, I suggest you do your grading in 32bit if you're not doing it already.

If you do that and you still have problems I suggest you try exporting as 4:2:2 or even 4:4:4 (x.264 already allows it). Choose a higher (4+) h264 profile too. Let us know how it worked out.

If you are exporting for streaming, there is no reason at all to use 4:2:2, 4:4:4, or 10-bit. YouTube and Vimeo are 4:2:0 8-bit, so if you upload anything else, you're just asking them to do the conversion for you, however they see fit. If you upload 4:2:0 8-bit, there'll be no resampling for the original size version, and no remapping of color values.

4:2:2 and 4:4:4 have nothing to do with grading. They are chroma spatial subsampling schemes. Grading does not alter images spatially. If exporting in 4:2:2 or 4:4:4 ever improves the image quality, it just means that the next tool in your workflow is doing a lousy job of chroma upsampling - and it is certainly the case that some tools have lousy chroma upsampling. But again, that's nothing to do with grading. Grading only manipulates color values.

You seem to not know the difference between chroma subsampling, color depth, and compression. Go read about YouTube's Viper system and how they do transcoding. It uses ffmpeg. When there is no scaling and no color space conversion and your input has the same chroma subsampling and color depth as the output, no resampling or remapping of color values takes place. Of course it is recompressed.

@balazar and you seem to not know the process and steps someone must take before the file is ever sent to YouTube. The color sampling, depth change takes place at least twice, perhaps three times or more BEFORE this, dude. If you're rendering out of your editor straight to 4:2:0 or rendering straight to 4:2:0 h.264 and submitting that you are not getting good quality before YouTube sees it or after. Period.

Why don't you re-read what you first responded to and grok on it a little bit. Here, I'll paint you a picture though:

1) raw footage 4:2:0 8bit

2) transcode to 4:2:2 8bit or 10bit [incurred transcode upsample #1] so CS6 doesn't muck it up...now it's fat 4:2:0 but no chance for "rain"

3) import into editor, work in float, [incurred transcode upsample #2] do color correction, motion graphics, additional layers...now your footage exists as 4:4:4 and your original footage has now been manipulated so that it no longer represents the original 4:2:0 and, ideally, has be enhanced to restore some of the color decimation and damage that 4:2:0 (or even 4:2:2 sampling does to an image) and then you've also potentially mixed together imagery and pixels that originated as 4:4:4 floating point

...now you have a decision gate. Do you...

a) render your comp/timeline to some 4:2:0 codec [incurred transcode downsample #1][visually obvious degradation #1] prior to compression to h.264

b) render your comp/timeline directly to h.264 codec for upload to streaming site [incurred transcode downsample #1][visually obvious, in the extreme, degradation #1]

c) render your comp/timeline to a high quality online codec like ProRes 422 [incurred transcode downsample #1][subtle visual degradation #1]

d) render your comp/timeline to a high quality online codec like ProRes 422HQ (same as above but even more subtle to invisible image degradation)

e) render your comp/timeline to a high quality online codec like ProRes 444 [transcode @ full quality][visually identical to the quality within the timeline preview]

...if you said either "a" or "b", you're doing it wrong and there's no need to continue from here. Besides that, it's pretty funny to champion YouTube for anything but their ubiquity. Who cares what's under the hood if the results are merely passable. I don't need to know the name of it. I already know I get better results at Vimeo.

If anyone besides BurnetRhoades cares, I've done the experiments to prove that when you upload an 8-bit YUV 4:2:0 video to YouTube in h.264 mp4 format, they do not do any chroma resampling, and the color values are used as-is without any remapping or conversion. (same as ffmpeg or mencoder would do when recompressing) We can use some other topic about the best upload format for YouTube.