Fraps to YouTube with H.264

Discussion in 'Video Encoding' started by raffriff, Jan 3, 2012.

  1. raffriff

    raffriff Moderator Staff Member Site Contributor

    These settings are for x264vfw, but can be adapted to any H.264 encoder. (updated & expanded from this thread) These settings are tweaked for the absolute max quality

    tl;dr: H.264; CRF mode; Ratefactor 19 (good) to 16 (best)

    [EDIT: for much higher encoding speed at "almost" max quality, scroll down to post #5]
    [EDIT: for smaller files (but slower encoding speed), scroll down to post #7]
    [EDIT: added equivalent FFmpeg arguments for each recommended setting]
    [EDIT: screenshot added]

    Preset: Faster or VeryFast (quicker encoding but larger file size)
    Tuning: None
    Profile: Auto
    Level: Auto
    Fast decode: on
    Zero Latency: off
    Rate Control: CRF
    (Constant ratefactor tries to make the video bitrate as low as possible
    for a set quality level, no matter if it's high resolution or low, simple or complicated;
    NOTE: higher numbers = higher compression = lower quality)
    Ratefactor: 19 (good) to 16 (best)
    Ratefactor is loosely related to bitrate:
    (the actual bitrate depends on the source material - sometimes by a large amount)
    minimum quality:....CRF 26-29 (~ 2000 kbps)
    good quality:.......CRF 20-24 (~ 5000 kbps)
    awesome quality:....CRF 16-19 (~ 10,000 kbps)
    "lossless":.........CRF 6-0...(> 20,000 kbps)

    (YouTube encodes at about 2500-3500 kbps, and we want to encode at a higher
    rate than that, but an extremely high bitrate would be wasted.)

    When encoding with VirtualDub
    • Check "VirtualDub hack" in your x264vfw options
    • Add the following in Extra commands for best color (more here):
      --colormatrix bt709
    Some versions of x264vfw don't have Presets available - Presets are extremely helpful, so make sure you get the download from Sourceforge.

    Equivalent options for FFmpeg:
    -f avi -acodec copy -vcodec libx264 -crf 19.0 -pix_fmt yuv420p -preset veryfast
    Equivalent settings for StaxRip:
    Device = x264 YouTube HQ
    Config Codec:
            Quality = 19.0
            Preset = Veryfast
            Tune = Fastdecode
            Device = [Disabled]
            Profile = [Auto]
            Mode = [Quality]
            [all settings default]
        Frame Options:
            [all settings default]
        Rate Control:
            [all settings default]
            Fullrange = [Off]
            [all others settings default]
    I sometimes boost the white levels, sharpness and saturation to make up for losses that occur at the
    YouTube end.

    MP3 constant bit rate; AAC constant bit rate; or PCM uncompressed (I prefer the last).

    If you upload at over 30 fps, it seems your framerate will be divided in two by YouTube; see here.

    To upload a "1080" video, height at least 1080.
    To upload a "720" video, height at least 720.
    Black bars (letterboxing) will be visible unless the aspect ratio is 16:9 - see here.

    After reading this thread on the Sony forum and watching this tutorial, I would advise any Sony
    users to follow those recommendations. They are the product of a long evolution involving
    a large group of smart videographers. I've revised my settings slightly to bring them closer to theirs.

    For YouTube, make sure you output Rec601 levels (luma range 16-235, "TV Range") as per the
    tutorial above. Fraps footage is full range. If your workflow is Fraps->VirtualDub->x264,
    you'll get correct TV range. In other cases I'm not sure - but I know how to find out, using the
    following [ EDIT see new, easier-to-use ->drag and drop batch file ]
    Updated 11 August, 2013 - no zerolatency
    Last edited: Jan 11, 2014
  2. raffriff

    raffriff Moderator Staff Member Site Contributor

    For home theater (or self hosted video, or any case where the video will not be re-encoded before
    the viewer sees it), use these settings. You can actually get away with somewhat lower quality than you need if going to YouTube etc. Don't boost the sharpness or saturation as much, either.
    Preset: Medium or Slow
    Tuning: None
    Profile: Auto
    Level: Auto
    Fast decode: off
    Zero Latency: off
    Rate Control: CRF
    Ratefactor: 22 (19-24)

    File size will be much smaller.

    Equivalent options for FFmpeg:
    (you might have to change the audio codec, depending on your ffmpeg installation)
    -f avi -acodec libfaac -ar 44100 -ab 160k -vcodec libx264 -crf 22.0 -pix_fmt yuv420p
  3. raffriff

    raffriff Moderator Staff Member Site Contributor


    Update March 23, 2013: H.264 works great as an archiving (compact long-term storage) codec, but you should transcode to a lossless format for editing. Attempting to use x264 footage for editing with the settings I posted previously (with option "--keyint 1") can result in macroblocking issues (see post #9) Frame seeking seems flaky as well.

    So my recommended intermediate (source for further video editing) codec is a lossless one like Huffyuv, Lagarith, DNxHD, UT Video - whatever works best with your editing software. All these lossless codecs are excellent for editing: they are fast decoding and all frames are keyframes. File size is on the large side though, about comparable to Fraps videos. Huffyuv is the oldest (I think) and the most universally compatible. DNxHD is needed if you want to compress with Handbrake.


    H.264 settings for archiving (compact long-term storage):
    Preset: Medium or Slow
    Tuning: None
    Profile: Auto
    Level: Auto
    Fast decode: off
    Zero Latency: off
    Rate Control: CRF
    Ratefactor: 16 or lower​
    --fullrange on OR --range pc
    (some versions of x264 accept --fullrange on, some accept --range pc, but they are equivalent AFAIK)​

    Equivalent options for FFmpeg:
    -f avi -acodec copy -vcodec libx264 -crf 16.0 -pix_fmt yuvj420p -preset medium -x264opts fullrange=on
    Size is about 1/10 of the original Fraps file.

    *********** WARNING ********************
    There is always a risk of something going wrong when trying to save disk space this way. You could try to use the file for editing six or twelve months later and find something wrong with no way to fix it. Maybe some frames are missing or corrupted. Maybe the colors don't match. Et cetera. :confused: It's safer to buy more hard disk space and keep the original files!

    Updated June 18, 2012
    Updated Sep 1, 2012 - remove Lagarith
    Updated March 23, 2013 - withdraw recommendation of x264 as an intermediate format; warning.
  4. raffriff

    raffriff Moderator Staff Member Site Contributor

    This article on the MeGUI wiki explains all the x264 settings...

    I tweaked settings for the best looking test video when encoding at only 2500 kbits/s (this exaggerates flaws in encoding), then verified that it looked OK after uploading to YouTube. Then I tested the YouTube round-trip at higher bitrates: 3300, 4000, 5000, 7000 and finally 9000 kbits/s. [in terms of CRF, that would be CRF=26, 24, 22 and 16] The YouTube video kept improving, in smaller and smaller increments, until I lost interest in uploading anything larger.

    Zero latency aka fast start is recommended by YouTube (EDIT 11 Aug 2013 - page deleted, and that's not what the page said anyway: fast start is not the same as zerolatency)

    Preset=Fast and Fast Decode each add about 5-10% to file size, but they seem to help the quality of the final YouTube video. If file size is a problem, and you've already got ratefactor at CRF 22 or more, try setting Preset=Slow and disabling Fast Decode.

    What does "Quality" mean?
    Simplified: if we think of compression as turning your video into "blocks" (like the Minecraft universe), lower quality = bigger block size. A given quality level (aka ratefactor) will always have the same apparent quality. H.264 knows where it can get away with bigger blocks where they won't be noticed, depending on picture content and motion. Bit rate will go up or down as required. Don't worry about bitrate too much unless you are live streaming or going direct to DVD, etc. Find a quality level you can live with and stick to it.
    Last edited: Aug 11, 2013
  5. raffriff

    raffriff Moderator Staff Member Site Contributor

    With some minor tweaks, you can encode twice as fast (or more) than you can with the settings in post #1. File size will be larger for the same video quality:
    Preset: Ultrafast
    Tuning: None
    Profile: Auto
    Level: Auto
    Fast decode: on
    Zero Latency: off
    Rate Control: CRF
    Ratefactor: 19
    --non-deterministic --sliced-threads

    Equivalent options for FFmpeg:
    -f avi -acodec copy -vcodec libx264 -crf 19.0 -pix_fmt yuv420p -preset ultrafast -x264opts non-deterministic=1:sliced-threads=1

    EDIT - for screaming fast encodes with multicore processors (and even larger files),
    add "--keyint 1" to the command line;
    or for ffmpeg, insert "--keyint_min 1 -x264opts keyint=1" like so:
    -f avi -acodec copy -vcodec libx264 -crf 16.0 -pix_fmt yuv420p -preset ultrafast -keyint_min 1 -x264opts keyint=1:non-deterministic=1:sliced-threads=1
    This makes each video frame stand on its own instead of being part of a large group (GOP). It allows each CPU core to work a separate video frame, without waiting for other frames to finish processing. So depending on the number of cores, you may see another doubling of speed - or more. You should use ratefactor 16 or 17 to preserve quality -- quality seems to go down a bit (see post #9) when the codec is "abused" this way.

    UPDATE - here's a report from user billman:
    Updated 11 August, 2013 - no zerolatency
    Last edited: Aug 11, 2013
  6. raffriff

    raffriff Moderator Staff Member Site Contributor

    Some people have mentioned that the resulting output file is too big. OK, here's how the recommended settings affect output file size in x264 and x264vfw.
    • preset=veryfast (fast encoding) vs. medium (slow encoding but 20% smaller)
    • fast decode=ON (seems to help YouTube compatibility) vs. OFF (makes file about 10% smaller)
    • ratefactor =16 (excellent quality) vs. 19 (good quality, 50% smaller file)
    • Compressing the audio makes the file another 10% smaller.
    So choosing all the "smaller file" options above should make a big difference. It's worth a try, although I personally prefer not using them - and living with a larger file.
    Updated 11 August, 2013 - no zerolatency
    Last edited: Aug 11, 2013
    odddotheheak and Resh Haydee like this.
  7. Hi! My favorite setting so far is the first one mentioned on this page. The file sizes are reduced significantly, but the quality is still great. Works great when played in VLC, or uploaded straight to YouTube like it's intended for. However, when I bring the files into Premiere Pro for editing, while playing back or scrubbing through the videos, my frames always drop.

    I found out that this does not happen at all when adding the extra command "--keyint 1" . But for some reason, the quality greatly suffers. It appears much noisier than if I hadn't put the command, and it seems like some macroblocking happens too. I'm clueless as to why this happens.

    I know I'm not exactly using the settings shown here appropriately for the purposes they're intended (and clearly labeled) for. I was just hoping there was a way to retain a similar file size like the one used in the first setting here, but be able to play the files back smoothly for editing in Premiere Pro.

    I hope I'm not asking for too much. Thank you so much again, raffriff for these awesome settings. There isn't any other place on the web I can find such in-depth instructions for my FRAPS to YouTube needs. Truly appreciate all your time and work. :)
  8. raffriff

    raffriff Moderator Staff Member Site Contributor

    Hi Resh, thank you for your kind words; they are truly appreciated.
    I've seen this before, and I believe (it's only a feeling) that x264's internal tradeoff algorithms are being thrown off by the extremely high bit rate demanded by high definition, low ratefactor, and lack of motion compensation compression (defeated with "--keyint 1") - and x264 is quantizing more to limit that bit rate. I've seen something like it in testing, and your experience confirms it: we are pushing the limits of x264 here. I think I'll withdraw my recommendation in post #3 of x264 as an intermediate, editable format. Now I'll say, use it as a compact archive format only (if you're short on disk space) (without --keyint) and transcode to a lossless format for editing. If disk space isn't a problem, keep all your intermediate footage in lossless. Thanks for your input!
  9. CRF for youtube is the worst thing you can do.
  10. Thalmor Wizard

    Thalmor Wizard Moderator Staff Member Site Contributor

    Please don't make a random statement like this without some sort of proof to back it up.
    raffriff likes this.
  11. I need some help. I captured at 1680x1050 on my computer with FRAPS, and I would like to upload to Youtube at 1920x1080 with good quality and not too big.

    To compress I use Virtualdub but I can't find a good configuration. Any advice step by step for a newbie ...
  12. raffriff

    raffriff Moderator Staff Member Site Contributor

    • get x264vfw.
    • select video compression=x264
    • in x264 config,
      • select "rate control" to "(CRF)"
      • set "ratefactor" to 19
      • for faster encoding, set "preset" to "veryfast"
      • enable "VirtualDub hack" option
    • select audio compression=uncompressed (PCM)
    • video menu, filters, add filter, "resize"
      • resize mode="Lanczos"
      • your video is 16:10 - taller than YouTube's 16:9 standard:
        • resize to 1920 pix wide and crop top and bottom; or
        • resize to 1080 pix high and have black bars left & right; or
        • see my post 16:9 video from a 16:10 monitor.
    • see my VirtualDub tutorial for more.
  13. Thanks for responding so fast :)

    The option that I have in my Virtualdub is Lanczos3, I imagine that there will be no problem with that, and as for the audio, I leave it in "Direct Stream Copy", this is correct or i must go to audio-compress-uncompressed. The ratefactor had it in 18, and the case is that there are videos that weigh many Gb and others not. I guess the difference may lie in the quality of what i captured.

    If I follow your instructions and the resulting file is still very large, what should I do to lower it? Compress again that file with these settings?

    Thanks for help :)
  14. raffriff

    raffriff Moderator Staff Member Site Contributor

    You're welcome!
    "Lanczos3" is it - I was typing from memory.
    I've always been using "uncompressed" audio but "Direct Stream Copy" should work.
    Yes, the video file size depends on the material being compressed.
    To make the video smaller, choose a slower preset ("medium" or "slow") and/or a higher ratefactor - no more than about 23 if you are uploading to YouTube, otherwise experiment. Don't compress it twice - go for the size you want from the start.
  15. Ok. Thank you very much for help :)
    raffriff likes this.
  16. Thalmor Wizard

    Thalmor Wizard Moderator Staff Member Site Contributor

    Just think I should clear up some incorrect information here. YouTube bases the quality options on the height value only. I can prove this because I've uploaded a lot of 1440x1080 videos to YT and the 1080p option is available. So might be wise to correct that :p
    raffriff likes this.
  17. raffriff

    raffriff Moderator Staff Member Site Contributor

    OK, will do, thanks :)
    Thalmor Wizard likes this.
  18. raffriff

    raffriff Moderator Staff Member Site Contributor

    I just edited all my posts in this thread to remove tune=zerolatency from my recommended x264 settings. I was just plain wrong about that, or at best, my advice was far out of date. If anyone feels zerolatency helps in some way, please let me know. Right now it looks to me like it is increasing file size with no benefit. Zerolatency is for streaming servers, and even then it's optional.
  19. I'm a bit confused about which preset to use. I am fine spending extra time in encoding if that results in better quality or smaller file size with the same quality. In your guide you posted a few things about presets - the original post recomments "Faster or VeryFast" with the note near Veryfast stating "quicker encoding but larger file size" so I'm assuming they produce the same quality and faster should output a bit smaller file size? However, later you mention preset Fast ("Preset=Fast and Fast Decode each add about 5-10% to file size, but they seem to help the quality of the final YouTube video.") - did you mean "veryfast" instead of "fast"? Since i noticed that the preset you suggest is "veryfast", so I assume it is the preset that produces the highest quality.

    Also, while I always thought that slower presets should yield smaller file sizes, for one of my encoded video a file encoded with "veryfast" preset was in fact smaller than the file encoded with "medium" preset... Also, what about the quality? I remember seeing a guide somewhere on the internet claiming that slower presets increase the quality, but how does it go with YouTube compatibility?

    Thanks in advance for answering :)
  20. raffriff

    raffriff Moderator Staff Member Site Contributor

    Hi Faalagorn, there are two basic compression "rate control" methods for size/quality tradeoff, usually called constant bitrate and constant quality.

    Constant bitrate is for fitting a video into a certain file size - such as a DVD disc. The bitrate of the compressed file (and therefore the size, which is bitrate x duration) is predictable, but the "quality" (as perceived by the human eye) can vary over a very wide range, depending on the source's compressibility.

    Constant quality produces the smallest file size possible at a given "quality" (as perceived by the human eye); apparent quality is predictable, but the compressed file size can vary over a very wide range, depending on the source's compressibility.

    For uploading to YouTube, we want a very high quality, because YouTube re-compresses the video, and in doing so, any tiny compression artifacts - not very visible to the human eye - get exaggerated. This process is not explained or documented by YouTube. The process seems to change quite often, with no notice to the public. There may be times when the video is not re-compressed. But in general, we want very high quality for our upload file, with size a secondary consideration.

    At the extreme, some people don't care about file size - they upload Fraps file without re-compressing them at all. Upload speed is a problem for most of us, so we want to compress our files. (Fraps files are lightly compressed, about 5:1, but we are talking about approximately 20:1 compression for upload to YouTube)

    The speed presets (veryfast, veryslow, etc) vary compression speed, adjusting size or quality (depending on the ratecontrol method) as required. In constant bitrate, faster = worse quality; in constant quality, faster = larger file size.

    These presets make lots of little changes behind the scenes, and the effect on size and apparent quality can be hard to predict: it's possible that under some circumstances, a file might get larger when you expect it to get smaller. As a side effect, faster presets require less memory during the compression process, and I believe (based on testing I did a while back - things might have changed since then) that they look better when uploaded to YouTube. At the extreme ("ultrafast") setting however, bitrate becomes so high (faster = larger file size = higher bitrate) that the compression program appears (in my experience) to sacrifice quality to keep the bitrate within reasonable limits, leading to possible compression glitches; this is why I recommend "veryfast"- it's fast, but not too fast.

    So to sum up, for our purposes we definitely want constant quality mode, and we need high quality. And finally, we would like the compression process to go as quickly as possible. If we care about file size, we can use a slower preset to get a smaller size while maintaining a constant quality.

    "Constant quality" is actually an approximation - no software can perfectly predict how "good" the final product will appear to the human eye, but in general, in x264 a quality (called "constant ratefactor" or CRF for short) setting of 18 means very, very high quality, and this what I recommend.

    Once the YouTube video is uploaded, we don't care about the original file - we can even delete it. This is why file size is low-priority for this particular situation.
    Last edited: Jan 4, 2014
    Thalmor Wizard likes this.

Share This Page