Personal View site logo
Make sure to join PV on Telegram or Facebook! Perfect to keep up with community on your smartphone.
Please, support PV!
It allows to keep PV going, with more focus towards AI, but keeping be one of the few truly independent places.
h.264 exporting at 10mbit or higher- 2 pass needed?
  • I was just wondering if anyone had had any experiences with exporting a final project at a very high bit rate (say 10mbit) and noticing a quality drop-off between 1 pass h264 and 2 pass h264?

    This can be a good time saver, for exporting final projects. I understand with low bitrates it makes sense, but is 2 pass needed at 10mbit+?

  • 22 Replies sorted by
  • 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).

  • And if the video in question has a resolution of 1920x1080 pixels, then 10MBit/s is not at all a "very high bit rate" - there is a reason why movies on BluRay discs typicall use about 25 MBit/s (out of 54 MBit/s that the BluRay is specified to support, max.).

    10MBit/s for a 1080p movie is enough when there are lots of non-complex scenes that a 2-pass encoding can benefit from, but doing a 1-pass encoding at 10 MBit/s would be sure to result in nasty compression artefacts whenever there is complex motion in a scene.

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

  • Hi, I don't want to create another topic about compression so I'll ask here.

    I don't know much about compression but I noticed something I couldn't explain : I was grading a 100MBit/s gh2 rush, the quality was good at this stage (no artifacts or what) I did an uncompressed export (using Lagarith Avi Codec) then a H264 2pass VBR @ 20MBit/s export but I had noticeable macroblocking in the shadows.

    I do understand that H264 is a lossy codec, but since the original rush was perfect (quality wise), and my H264 bitrate pretty high (or regular for BluRay) shouldn't the H264 version look great too ? I'm wondering if it's an encoder settings issue or if there's nothing to do ?

    Thank you for your help !

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

  • @duartix : Thank you for answering. Concerning 2pass VBR I get it now.

    I did a bunch of different exports but even with a CRF set at 16 (giving an average bitrate of 37mbits/s) my clip still looks ugly.

    If i pushed the grading too far, I would have seen the footage falling apart even in after effects right ? As I said before, I'm learning compression so I apologize if my questions sound stupid.

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

  • x264's CRF rate control is good for presentation output when you want high efficiency. For mastering, use constant quantizer encoding with equal quantization in all frame types, like this:

    qp=20:ipratio=1:pbratio=1

    A lower QP value means higher quality. A value of 18-20 means very good quality, and 0 means lossless.

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

    I was grading a 100MBit/s gh2 rush, the quality was good at this stage (no artifacts or what) I did an uncompressed export (using Lagarith Avi Codec) then a H264 2pass VBR @ 20MBit/s export but I had noticeable macroblocking in the shadows.

    It would make more sense if you had transcoded it to some robust codec before grading. Prores, DNxHD, Cineform etc.. Maybe Lagarith is to hard to play in realtime, but it has been a while since I had used it last time.

    Nevertheless, how did that "intermediate" Lagarith Avi look like?

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

  • @inqb8tr : I did both, straight from gh2 and transcoded in uncompressed 10bit 4:2:2 using 5DtoRGB dut didn't notice any visual difference, both looked to same : they looked great.

    @trevmar : Don't get me wrong, I'm not saying MeGui is a bad tool ;) The issue is caused by something that I didn't manage to spot yet.

    To sum up : if my transcoded footage is flawless, there's no reason why I would get some macroblocking/artifacts issues after compression ( using proper settings) ?

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

  • @duartix if you do your grading in 32bit and do anything more than conservative you need to export from there as either 422HQ or, for heavy grades, 444 to not re-introduce color-sampling and transcoding artefacts.

    422HQ is 10bit but this is still a down-grade from the absolute gamut (potential) of quality and information contained within AE and visible in the viewport. Especially if you're adding motion graphics or other non-h.264 layers to the footage. 444 is the only way to be sure you've got a what-I-saw-is-what-i-get clip to encode for streaming.

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

  • @balazer What you see on both youtube and vimeo are further processed and stepped down on compared to what you upload. You're not seeing what you send them, no matter how you send it to them. That is a fact.

    Exporting from your timeline to less than 422 or 422 HQ results in a pre-h.264 file that doesn't look as good as the same footage inside AE. That is also a fact.

    You're confusing yourself in the second paragraph, or, at best, tangenting unhelpfully. You're also not uploading videos that look as good as they could if you were doing them with a better paradigm but, your choice.

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

  • Deleted thanks.

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

  • LOL, color grading doesn't affect your image spatially? Bollocks. If you're doing it right it sure does.

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

  • Zzzzzzz.