VideoHelp Forum
+ Reply to Thread
Page 1 of 4
1 2 3 ... LastLast
Results 1 to 30 of 120
Thread
  1. Has anyone here read or seen this?

    http://compression.ru/video/codec_comparison/h264_2012/mpeg4_avc_h264_video_codecs_comparison.pdf

    Supposedly x264 beats out the others in terms of PSNR. The reason I ask is maybe a better workflow would be to export losslessly from PPro and encode using x264 instead of AME?

    Then again maybe this is a biased study and YMMV?
    Last edited by SameSelf; 8th Jan 2015 at 16:34.
    Quote Quote  
  2. I'm a MEGA Super Moderator Baldrick's Avatar
    Join Date
    Aug 2000
    Location
    Sweden
    Search Comp PM
    File not fnd.
    Quote Quote  
  3. Found the problem in the link and should be fixed now. Sorry.
    Last edited by SameSelf; 8th Jan 2015 at 16:41.
    Quote Quote  
  4. That's quite a loaded question. "Best" by what criteria ? For what scenario ?

    For objective metrics, like SSIM, PSNR, you can adjust the encoding settings to make it "score" higher and it usually does score the highest. But those metrics can be problematic, and don't necessarily correlate with viewer subjective assessment of "quality". Also, almost nobody uses --tune PSNR or --tune SSIM for actual encoding scenarios, because although they score higher, they often look worse using those settings. So those tests from MSU are of questionable value.

    Overall , x264 is considered the "best" overall by many people for general purpose use. It is considered the "gold standard" for AVC encoders. Even HEVC encoders get measured against it. But it's not perfect, there are weaknesses, and it's not the "best" at everything in every scenario.

    Certainly at lower to mid bitrate ranges, there is hardly any argument from anyone that x264 offers the best compression efficiency for AVC encoders. The difference between various AVC encoders is quite high at low bitrates. At higher bitrate ranges, it becomes more difficult to see differences. Also at higher bitrate ranges, some commercial encoders might be better in some aspects, yet worse in others. (By commercial encoders, I mean more expensive ones than AME's licensed Mainconcept AVC version)

    You can frameserve out of PP using debugmode frameserver /advanced frameserver, or use x264pro plugin($) as other options instead of lossless intermediate export. But some people don't care. So what if you need slightly more bitrate to get similar quality ? Maybe the ease of use is more important to them. At high enough bitrates, everything looks good
    Quote Quote  
  5. Member Cornucopia's Avatar
    Join Date
    Oct 2001
    Location
    Deep in the Heart of Texas
    Search PM
    Yes, x264 is the best...at some things for some people.

    Scott
    Quote Quote  
  6. I should mention that the reason I am digging into bit rate in such detail is that I struggle streaming video to all the wireless devices in my house.

    I also found this provocative chart.
    http://www.extremetech.com/wp-content/uploads/2013/07/HEVC-Encode.jpg
    Last edited by SameSelf; 15th Jan 2015 at 10:42.
    Quote Quote  
  7. Yeah, again we see that PSNR-Y (that chart is only measuring the Y channel (black and white), not the color information or Cb, Cr channels) . It can be a useful metric, but you have to understand the intricasies of the testbed, and the limitations of PSNR testing. (It has to be put into proper context)

    For wireless streaming to current devices, and lower bitrates as the goal, x264 will be the clear winner right now for your purposes

    Certainly at 4K resolutions, HEVC hands down is the clear winner. AVC (any flavor of encoder, including x264) doesn't even come close. For today's 1080p scenarios at very very low bitrates, using HEVC is going to be beneficial as well. At "normal" ranges, right now HEVC is immature and the encodes typically lack details. In general , they appear "oversmoothed". It's much like early days of AVC development, maybe 10 years ago. Everything looks like "plasticky". Also, HEVC takes a lot more resources to encode and decode. Most devices cannot handle HEVC right now (some do, and some even record HEVC with a dedicated HEVC chip). So right now, the potential benefits of HEVC don't outweight the negatives for most scenarios.
    Quote Quote  
  8. Originally Posted by poisondeathray View Post
    For objective metrics, like SSIM, PSNR, you can adjust the encoding settings to make it "score" higher and it usually does score the highest. But those metrics can be problematic, and don't necessarily correlate with viewer subjective assessment of "quality". Also, almost nobody uses --tune PSNR or --tune SSIM for actual encoding scenarios, because although they score higher, they often look worse using those settings. So those tests from MSU are of questionable value.
    The funny thing is according to my tests, even without the two "tune" options you mentioned, PSNR and SSIM both increase with each increasingly slower preset, with "placebo" scoring higher at PSNR AND SSIM every time.

    With some sources, like the uncompressed Sintel trailer, x264 with "placebo" scores 61db in PSNR and .997 at SSIM, both incredible values and the visual quality matches what the metrics suggest. With that source you don't hit 51db PSNR and .98 SSIM until you hit the "fast" preset. Of course with other sources you never see scores that high.

    To answer the OP's question, x264 is the best, without a doubt, at it's price point, i.e. it's free and accessible from within a cli and enough gui's that it's difficult to justify the cost of the pro grade AVC encoders for anyone but those that produce high end content that generates significant income.

    To give you an example, one of the largest adult sites in the world, Brazzers, uses the x264pro plugin for Adobe Premiere for their content with the "slow" preset. On the other hand Digital Playground, which is widely considered to have the crispest, cleanest videos available uses the excellent Sirius Pixels encoder:

    http://www.siriuspixels.com/customers.php

    http://www.siriuspixels.com/imagegallery.php

    The list of Blu-Rays created with this encoder is impressive and among the highest quality I have ever seen. This encoder is based on the "old" CCe HD AVC encoder and if you can afford it you won't find a better product.

    It's not cheap though, this similar product, not sure if it's made by the same people but has a similar name and is based on the same code base costs comparable to what Main Concept's offering do:

    http://www.wcliff.org/store/ss-index.html
    Quote Quote  
  9. Originally Posted by sophisticles View Post
    Originally Posted by poisondeathray View Post
    For objective metrics, like SSIM, PSNR, you can adjust the encoding settings to make it "score" higher and it usually does score the highest. But those metrics can be problematic, and don't necessarily correlate with viewer subjective assessment of "quality". Also, almost nobody uses --tune PSNR or --tune SSIM for actual encoding scenarios, because although they score higher, they often look worse using those settings. So those tests from MSU are of questionable value.
    The funny thing is according to my tests, even without the two "tune" options you mentioned, PSNR and SSIM both increase with each increasingly slower preset, with "placebo" scoring higher at PSNR AND SSIM every time.
    Why is it "funny" ? This would be expected behaviour with increasingly slower presets.

    Now try --tune PSNR or --tune PSNR with the same preset then report the results at a given bitrate (or do serial CRF encodes until the bitrates are the same)


    With some sources, like the uncompressed Sintel trailer, x264 with "placebo" scores 61db in PSNR and .997 at SSIM, both incredible values and the visual quality matches what the metrics suggest. With that source you don't hit 51db PSNR and .98 SSIM until you hit the "fast" preset. Of course with other sources you never see scores that high.
    But what rate control setting for those observations ? What bitrates and filesizes? For example, I doubt "placebo" at CRF 30 would hit 61dB

    Yes, results can vary by sources, but with metrics that high, there is a strong correlation with subjective "quality" and difficult to distinguish differences.
    Quote Quote  
  10. Originally Posted by poisondeathray View Post
    But what rate control setting for those observations ? What bitrates and filesizes? For example, I doubt "placebo" at CRF 30 would hit 61dB

    Yes, results can vary by sources, but with metrics that high, there is a strong correlation with subjective "quality" and difficult to distinguish differences.
    I downloaded the Sintel trailer from here:

    https://media.xiph.org/

    And I decided to target a 1 pass VBR at what I consider minimum streaming bit rate for a 1080p video, namely 8000 kb/s. I tried 2 pass as well and remarkably enough for most presets PSNR and SSIM actually went DOWN! Shocking to say the least.

    I personally am not a believer in so-called CRF encoding, many of the short-comings of x264 are directly attributable to this rate control system and it also smacks to me of an absurd logical gymnastic needed to justify it's use. The claim is that objective metrics, such as PSNR and SSIM can't be trusted when determining quality yet these same people have no problem trusting x264 to determine a quality from an arbitrary metric like CRF value. They know that with CRF x264 tends to under allocate bits to fast moving scenes and areas where it believes you won't notice the quality hit in order to allocate the bits to an area where it thinks it will be most noticeable, they also know that x264 has a problem with fades/cross fades and black/dark areas yet the don't put 2 and 2 together and realize that many of the shortcomings are due to CRF rate control.

    To each his own, I know I would never by any content from them.
    Quote Quote  
  11. As I recall, it took a couple of years of development for x264 to really come into its own. HEVC needs more development, obviously.

    I remember an interesting post on Doom9, which said HEVC presently tends to throw away more detail in favor of motion, as compared to AVC. It is most apparent with, say, a scene with leaves fluttering in the wind, or fast moving water. At very low bitrates, x264 will obviously favor more detail, at the expense of increased temporal artifacting (specifically a shimmery look to the motion). Of course, that's not an indictment of x264, but rather of those who insist on setting the bitrate far too low, but the comparison was interesting.

    Once mature, HEVC is supposed to be...what, twice as efficient as x264?
    Pull! Bang! Darn!
    Quote Quote  
  12. Originally Posted by fritzi93 View Post
    Once mature, HEVC is supposed to be...what, twice as efficient as x264?
    That is the claim, I hope that it doesn't take as long to mature as it took x264, even 5 years is a long time to wait.

    Personally I am interested in seeing what Maxwell's new HEVC encoder is capable of, hopefully someone will write the code needed to use it and someone will do some tests.
    Quote Quote  
  13. I now see (after more research and all your replies) why this was such a loaded question. When I first asked the question, I didn't understand that there are dozens of encoders out there for just H.264. I naively assumed that if you specify H.264, that dictated the algorithm, and that that meant there were no tangible differences between encoders like AME's Mainconcept or x264. Oh how wrong I was!

    After some research here is how I see my situation.

    - I have invested what I consider a princely sum into Adobe. I thought it was high end approaching what is done in Hollywood. Now I know better.
    - Hollywood uses pro encoders that use multi-passes and virtual passes to encode scene by scene.
    - I have no interest in paying a few thousand for a pro encoder and rather save that money for gear.
    - So it sounds like I am left with relying on the best free tool out there i.e. x264.
    - Maybe in a few years we will all be using HEVC, but I got to get a 4K camcorder first!

    Thanks everyone for the very educational replies.
    Quote Quote  
  14. Folks that start to shoot video or some kind of production from whatever level usually assume that encoder is foremost important thing to plan for, but it is not. Using premiere for example one can just crank up bitrate far enough and it is ok. Far more important it is how things are going to be shot. Cameras, tripods, monopods, stabilization, lighting, skilled editing that would not mess up whatever one already has. And anyway, if video is shot the way it suppose to be, it does not even need that much bitrate. Shallow DOF, when object of interest is properly lit push bitrate down etc.
    You can shoot a bride underneath a tree with cheap camcorder, with huge DOF where you have to encode a million of twittering leaves at the same time will produce a bitate of 30.000kbps and still that would not be enough. Applying shallow DOF suddenly those leaves go out of focus or are they not that sharp and bitrate goes rapidly down. Encoding is all about a bitrate. In reality the question always is: For this bitrate , would my footage look well encoded? If yes, then you just might waste bitrate, but who cares, it is BD or DVD anyway. Using CRF avoids that, you encode bitrate that is just about needed, but you have to go with that x264 for example. For home videos one perhaps should not waste a room and encode CRF.
    Last edited by _Al_; 9th Jan 2015 at 18:23.
    Quote Quote  
  15. That report is from 2012 before H265 existed. x265 outputs better quality than x264 now but not significantly. However the encoding time is significantly higher so it isn't worth it to most. I know I know, I bragged somewhere here how I always immediately adopt the best quality encoder as soon as I hear of it but... my once ultra-powerful 4 GHz Pentium D which took a lot of electricity and noticeably heated the room up would encode at only 3 fps with x264. When I got my i7 computer and was able to encode 720p in real-time, this was a godsend and major relief.
    I do NOT wanna go back to those ugly dark ages of 2 fps encoding that take all night to finish.
    Quote Quote  
  16. Member
    Join Date
    Mar 2011
    Location
    Nova Scotia, Canada
    Search Comp PM
    In my experience ... which is much more limited than some of the above posters ... h.264 is better than most but it is because it has a lot more encoding features/parameters. This makes it more complex to use. And the problem is that there aren't any magic settings that work for all input.

    So, IMHO, for those who haven't quite got the hang of it yet, xvid may actually give you better results because there are fewer parameters to frak up.
    Quote Quote  
  17. Originally Posted by Hoser Rob View Post
    there are fewer parameters to frak up.
    One way to eliminate that is just use simple command line, avoiding softwares behind back settings or for example I used to forget to turn off --tff flags in MeGui, etc., using simple command line , you have those couple of settings right in front of you, no need to set everything.
    Quote Quote  
  18. Or use built-in profiles if you don't want to bother with various parameters.
    Quote Quote  
  19. in Megui, you can use profile but if you forget --tff switched on somewhere you get --tff encoded,

    we all have different habits, but basically , the way I see it, one have to specify reference frames, because slower presets can increase that number that could only cause problem with hardware players, buffers should be specified always and then just choose CRF number and it is fine. Maybe profile could be specified if using smaller resolution to give it --profile main and that's it. x264 uses defaults for the rest.
    For example:
    Code:
    regular 1920x1080............x264  --crf 18 --ref 4 --vbv-bufsize 30000 --vbv-maxrate 30000 --output out.h264  input_1920x1080_progressive.avs
    regular 1280x720.............x264  --crf 18 --ref 6 --vbv-bufsize 18000 --vbv-maxrate 18000 --output out.h264  input_1280x720_progressive.avs
    interlaced video.............x264  --crf 18 --ref 4 --vbv-bufsize 30000 --vbv-maxrate 30000 --tff --output out.h264  input_1920x1080_interlace.avs
    to increase compresibility.. x264  --crf 18 --ref 4 --vbv-bufsize 30000 --vbv-maxrate 30000 --preset veryslow --output out.h264  input_1920x1080_progressive.avs
    lower resolution.............x264  --crf 18 --ref 3 --vbv-bufsize 10000 --vbv-maxrate 10000 --profile main --output out.h264  input_640x360_progressive.avs
    1000kbps web stream..........x264  --crf 18 --ref 1 --vbv-bufsize 1100  --vbv-maxrate 1000 --profile baseline --level 3.0 --output out.h264  input_640x360_progressive.avs
    (or profile main)
    some easy GUI cannot specify buffers, but using CRF and buffers goes hand in hand or there should be limit with 2pass as well,
    Last edited by _Al_; 10th Jan 2015 at 16:22.
    Quote Quote  
  20. Originally Posted by Hoser Rob View Post
    In my experience ... which is much more limited than some of the above posters ... h.264 is better than most but it is because it has a lot more encoding features/parameters. This makes it more complex to use. And the problem is that there aren't any magic settings that work for all input.
    So, IMHO, for those who haven't quite got the hang of it yet, xvid may actually give you better results because there are fewer parameters to frak up.
    Xvid's default settings can't come close to x264's default settings for quality. Well, Xvid can't really come close to x264 at all, except maybe using a custom matrix and a fairly high bitrate. If you want a good looking encode, x264's default settings will do better than Xvid every time at a given bitrate, although usually it'll do better at lower bitrates.

    I have this theory I've never scientifically tested, but it's based on the no free lunch principle. If you were to tweak an x264 setting to improve the quality in a particular area, maybe to encode more fine detail, or to reduce the blocking in a dark, harder to encode scene etc..... that sort of thing..... any increase in quality invariably increases the bitrate...... no free lunch. As it turns out, lowering the CRF value also increases the quality along with the bitrate, so I mostly fiddle with the CRF value rather than change "advanced" settings if I want to up the quality. A couple of times I've tried "tweaking" and the result was fine, but lowering the CRF value had a very similar effect without increasing the bitrate as much. I don't know if that's typical, but I have wondered......
    Quote Quote  
  21. Originally Posted by hello_hello View Post
    Originally Posted by Hoser Rob View Post
    In my experience ... which is much more limited than some of the above posters ... h.264 is better than most but it is because it has a lot more encoding features/parameters. This makes it more complex to use. And the problem is that there aren't any magic settings that work for all input.
    So, IMHO, for those who haven't quite got the hang of it yet, xvid may actually give you better results because there are fewer parameters to frak up.
    Xvid's default settings can't come close to x264's default settings for quality. Well, Xvid can't really come close to x264 at all, except maybe using a custom matrix and a fairly high bitrate. If you want a good looking encode, x264's default settings will do better than Xvid every time at a given bitrate, although usually it'll do better at lower bitrates.

    I have this theory I've never scientifically tested, but it's based on the no free lunch principle. If you were to tweak an x264 setting to improve the quality in a particular area, maybe to encode more fine detail, or to reduce the blocking in a dark, harder to encode scene etc..... that sort of thing..... any increase in quality invariably increases the bitrate...... no free lunch. As it turns out, lowering the CRF value also increases the quality along with the bitrate, so I mostly fiddle with the CRF value rather than change "advanced" settings if I want to up the quality. A couple of times I've tried "tweaking" and the result was fine, but lowering the CRF value had a very similar effect without increasing the bitrate as much. I don't know if that's typical, but I have wondered......
    All you really have to worry about is whether your source is film or cartoon. For film, no need for more than 5 refs and cartoon you may as well use all 16. That setting makes the biggest difference in quality. The rest don't make too much of a difference. The problem is people use shitty settings as default. Everybody has an i7 right now, crank everything to the max except ME search and ME range. After that, just choose 3-5 refs for film and 10-16 for animation. A lot simpler than it looks.

    As a side note, x264 is twice as better than XviD even if XviD's settings are cranked to the max. And x264 at its fastest settings encodes faster than XviD and STILL has better quality. Single-thread speed, let alone multi.
    Quote Quote  
  22. Originally Posted by hello_hello View Post
    I have this theory I've never scientifically tested, but it's based on the no free lunch principle. If you were to tweak an x264 setting to improve the quality in a particular area, maybe to encode more fine detail, or to reduce the blocking in a dark, harder to encode scene etc..... that sort of thing..... any increase in quality invariably increases the bitrate...... no free lunch. As it turns out, lowering the CRF value also increases the quality along with the bitrate, so I mostly fiddle with the CRF value rather than change "advanced" settings if I want to up the quality. A couple of times I've tried "tweaking" and the result was fine, but lowering the CRF value had a very similar effect without increasing the bitrate as much. I don't know if that's typical, but I have wondered......
    Most people don't seem to understand what "crf" is. They may know it stands for "constant rate factor" but it's, maybe purposely, masked in this pseudo-magic illusion of some super secret algorithm that is capable of unheard of till now capabilities.

    CRF values represent a quantizer, the lower the quantizer the bit rate is used and vice versa. The other thing tha most believe is the notion that CRF uses the same algorithm as 2 pass, what CRF does is use the same rate control algorithm as 2 pass, not the same thing.

    CRF works like this, it analyses the file to identify fast moving scenes, dark scenes, flat scenes, like sky and then it under allocates bits with the intention of using those bits in slow moving scenes, brightly lit scenes, scenes were the developers believed you would be most likely to notice a quality lose.

    This mode however leads to a number of problems, such as the fact that at any given quantizer, the size and quality of the file will vary wildly with the movie content. For instance, if the source movie as 80% action, CRF will bit starve 80% of the movie and allocate those bits to the remaining 20% in an attempt to convince the user that x264 did a great job of encoding.

    On the other hand, if you have a movie with little to no fast moving scenes, CRF will balloon the bit rate.

    Anyone that has used x264 extensively is well aware of some serious short comings:

    x264 has a problem with dark areas, blacks in general and flat areas like skies.
    x264 has problems with fades and cross fades.
    x264 has a tendency to produce artifacts in the borders between a high detail area and a low detail area.

    These issues begin with CRF. Because CRF under allocates bits in the areas I described above the developers, evidently so in love with CRF mode that they were unwilling to abandon it, created a bunch of band-aids to alleviate the problems.

    The first was AQ, or adaptive quantization. If you read through the documentation you discover that AQ takes bits away from more detailed areas and tries to allocate them to flatter areas of the image and the AQ strength varies how much it biases on either end of the spectrum. If you don't use CRF there is no need for AQ.

    Same applies to fades and cross fades, x264 treats them with less importance and under allocates bits, Weighted P helps but again with no CRF much of this effect doesn't occur.

    Lastly the previously mentioned artifacts have to do with when CRF bit starves Psy-RD, this feature actually works quite well IF it has enough bit rate to work with, if it doesn't it tends to cause unseemly artifacts.

    As for the "no free lunch" principle, you are correct; bits can be thought of as money and bit rate as the cost of quality. As the desired quality goes up so too does the cost, if one wants to drive a Cadillac CTS-V one has to pay a nice sum of money for it, likewise if one wants to high quality encode one has to use a good amount of bit rate.

    The 2 most important factors governing quality are quality of the source and how much bit rate is used, everything else is secondary.
    Quote Quote  
  23. sophisticles, CRF is subject to the same bitrate volatility as any other mode, that's what the qcomp is for and why everyone sets it to something leaning towards constant quality.

    What exactly are you championing in favor of it anyway? 2pass mode? I do both on a regular basis and I'm not aware of either one producing better quality than the other. Both have the same flat area banding problems. If anything, 2pass mode starves proper motion vector information for the purpose of maintaining a constant average bitrate. That bites the quality's ass as much as CRF's shortcoming of not doing an analytical first pass.
    Quote Quote  
  24. Sophisticles, The business of encoding IS camouflage , there is no magic involved.
    One could tend to always explain things from the point of right bitrate, or some imaginary best possible result. But that is unknown for any given video, Nobody can guess bitrate and be right on the mark of supposed efficiency, it is basically like in the lottery, guessing bitrate, so CRF helps you out greatly, by doing its job and using 1pass only.

    So tell me, no sarcasm in this, I do not want to defend x264, I do not care, I'd like to know using 2pass, what bitrate to choose for video to be more efficient as oppose to 1pass CRF. Just 5-10 min for playing around to know where I stand regarding quantizer, not half a day only realizing that I am where I was in the morning, using 2pass. What'ss the trick?

    I think your point of view is "bucket" oriented, where you have bitrate as a given and than you tend to analyze things, but today there is no need to encode to size , only to be efficient and bang, dang, done.
    Last edited by _Al_; 11th Jan 2015 at 18:32.
    Quote Quote  
  25. I'd like to know using 2pass, what bitrate to choose for video to be more efficient as oppose to 1pass CRF.
    Since 2pas and 1pass crf use the same rate control in the backend and thus produce near identical output for the same output size this doesn't make sense.
    Use 2pass if you aim for a specific file size, otherwise use crf with a value that retains as much details as you want.

    What'ss the trick
    No trick two methods do reach different goals.

    I think your point of view is "bucket" oriented, where you have bitrate as a given and than you tend to analyze things, but today there is no need to encode to size , only to be efficient and bang, dang, done.
    The problem is always the definition of 'efficient' and/or 'quality', but that aside if you don't aim for a specific file size or bit rate crf is the way to go with x264.
    users currently on my ignore list: deadrats, Stears555
    Quote Quote  
  26. Originally Posted by Selur View Post
    The problem is always the definition of 'efficient' and/or 'quality'
    Every person has different point of view at that, sure. As for me, those terms would mean looking at the thing from regular viewing distance, not really noticing a difference from original, even on solid 50" or so, that's how I look at it, video sources would be camcorder or photo-camera. Yes, two people can have really different things on mind regarding quality, efficiency ... But oh my, there is UHD round the corner and everything is going to look like crap yet again, like those old avi's look now

    Or for example trying to encode web stream, where 2pass is waste of time, where CRF is very handy here as well, --vbv-bufsize --vbv-maxrate basically limits bitrate and lower CRF causes bitrate not to drop, only if bitrate is not needed, but again , for some totally unimportant subject perhaps.
    Quote Quote  
  27. Originally Posted by sophisticles View Post
    The other thing tha most believe is the notion that CRF uses the same algorithm as 2 pass, what CRF does is use the same rate control algorithm as 2 pass, not the same thing.
    I'm not quite sure I understand the distinction. I've compared CRF and 2 pass encodes at the same bitrate and they seem to be fairly identical. Are you saying that's not the case?

    Originally Posted by sophisticles View Post
    CRF works like this, it analyses the file to identify fast moving scenes, dark scenes, flat scenes, like sky and then it under allocates bits with the intention of using those bits in slow moving scenes, brightly lit scenes, scenes were the developers believed you would be most likely to notice a quality lose.

    This mode however leads to a number of problems, such as the fact that at any given quantizer, the size and quality of the file will vary wildly with the movie content. For instance, if the source movie as 80% action, CRF will bit starve 80% of the movie and allocate those bits to the remaining 20% in an attempt to convince the user that x264 did a great job of encoding.

    On the other hand, if you have a movie with little to no fast moving scenes, CRF will balloon the bit rate.
    Mmmmmm.... I understand what you're saying. I'm just not sure I'd necessarily look at it that way.
    Imagine 2 movies. The first has little fast action. The second has much more, but 20% of both movies contain exactly the same low action video. You encode them both with the same CRF value. Wouldn't the 20% that's the same for each movie be encoded exactly the same way each time? Identical bitrate? If so, saying CRF has "starved" 80% of movie two seems misleading to me, as it implies Peter was robbed to pay Paul, even though the identical video in each movie was encoded the same way each time.
    You might be of the opinion CRF allocates bits disproportionately, but that's a different thing.

    I've encoded a reasonable amount of clean, not much action video at low CRF values (CRF16 to CRF18) and the resulting bitrate has sometimes been surprisingly low, so I'm not completely convinced on the "balloon the bitrate" theory. Mostly I've given up trying to predict bitrates though. I don't seem to be able to look at a video and guess the resulting bitrate for a given CRF value very accurately.

    Originally Posted by sophisticles View Post
    Anyone that has used x264 extensively is well aware of some serious short comings:

    x264 has a problem with dark areas, blacks in general and flat areas like skies.
    x264 has problems with fades and cross fades.
    x264 has a tendency to produce artifacts in the borders between a high detail area and a low detail area.

    These issues begin with CRF. Because CRF under allocates bits in the areas I described above the developers, evidently so in love with CRF mode that they were unwilling to abandon it, created a bunch of band-aids to alleviate the problems.
    I'm not sure I subscribe to the band-aid point of view.....
    As an example, there's a dark, detailed scene not being encoded well at a given CRF value but the rest of the video looks fine, so for the dark detailed scene you give AQ strength a boost, or nudge Psy-RD a bit etc. As a result it's encoded far more accurately, but the bitrate increases considerably. Re-encoding the same section again using the original settings with a lower CRF value also encodes it more accurately, with a similar increase in bitrate.
    That's the sort of thing I've experienced a couple of times. I'm not saying it's always the case. Maybe "tweaking" a setting can improve the quality without as much of a bitrate increase as lowering the CRF value, maybe sometimes it's the other way around, but I guess I'm wondering if "tweaking" would tend to improve the quality more "efficiently" (less increase in bitrate) or whether for quality "X" the bitrate needs to be "Y" no matter what setting you change to get there..... if that makes sense.

    I understand what you're saying about CRF and how it allocates bits for perceived quality etc, and maybe there's areas where it tends not to allocate enough, but what's the alternative? Is there another method for allocating bits as efficiently while always outputting the same perceived quality? Personally, I think in the "percieved quality" department, x264 does a pretty good job at keeping it consistent throughout an encode for a given CRF value, even if it's not perfect.
    Last edited by hello_hello; 12th Jan 2015 at 09:17.
    Quote Quote  
  28. A CRF encode and a 2-pass encode in x264, slow preset, CRF=18, bitrate=3580:

    Click image for larger version

Name:	comp.png
Views:	2599
Size:	32.8 KB
ID:	29652

    As you can see the bitrate distribution is substantially similar. The videos themselves are substantially similar too.
    Quote Quote  
  29. Low light scenes,
    where while editing video, it could be seen right away that encoder might not distribute enough bitrate so getting start and end frames from NLE timeline and adding to x264 cmd line, for example --zones start-frame,end-frame,crf=14 that takes almost no time, one has to just remember that if using a bob deinterlacer before encoding, values for those start and end frames must be doubled, so for two chosen regions in video where quality is boosted to CRF 14 as oppose to overall CRF 18, it could be something like:
    Code:
    x264  --zones 20200,22000,crf=14/35000,40000,crf=14 --crf 18 --ref 4 --vbv-bufsize 30000 --vbv-maxrate 30000 --output out.h264  in.avs
    I understand that encoding video from timeline of a NLE and encoding a movie could be two different things, because one can get familiar enough during editing or even during shooting feeling that video was not lit up properly, as oppose to encoding a movie. Where scenes can differ abruptly , example shot of space ship in the space, where that black thing around could introduce severe banding, but that shot basically stands out as oppose to video before and after, but that banding is very noticeable, because it is still shot and lots of banding around. This is not likely to happen if using a camcorder or photo-camera video shooting a "live action". In there, bad lit scenes come in bunches, having bad recording conditions.

    But that goes for 2pass encoding as well, but how one changes bitrate not knowing what bitrate is going to be distributed for that scene in the first place, one can guess and boost it anyway, --zones 20200,22000,b=1.5 (boosts bitrate 1.5x) but again result wiil be obvious only after encoding
    Last edited by _Al_; 12th Jan 2015 at 10:19.
    Quote Quote  
  30. I am getting ready for work and will be doing a 16 hour shift so I don't have the time to respond to a number of things said by a couple of you but I would like to point out that you will never find a single professional content provider that is using x264 (Brazzers is the most notable provider that comes to mind) that uses CRF mode for their content, not a one.

    There's an obvious reason for that, quality control and size control. These forums, and forums like it around the net, are filled with people asking questions like "I always use CRF 18 (or whatever number) for my encodes and have been happy with the results but for some reason movie 'x' is resulting in any of the following - poor quality, bigger size, etc, why is that".

    The responses always show that no one has the answer because their is no answer, CRF mode is kind of like shooting darts at a board with a blind fold one, you have no idea of what you're getting, you're choosing an arbitrary number that corresponds to an average quantizer and you're hoping for the best.

    With a bit rate based encode you choose an average bit rate that you know will give you uniform quality throughout the encode and you're done.

    But it's much more than that, the amateur encodes, those done for personal use also tend to use long GOP's as a way of squeezing the most compression out of a file but since this is lossy compression it comes at the expense of quality. There's a reason Blu-Ray, encoded with professional grade encoders like CCeHD use GOP lengths equal to frame rate and those pro caliber encoders do not have a CRF mode. I would think if it were really that good high end encoders like CCeHD and Ateme would have implemented their own versions by now. Professional content providers that offer content for sale via a website typically use double frame rate GOP lengths.

    So I find it odd that people use CRF and long GOP's, I think x264 defaults to 250 frames and the developers. by their own admission mind you, cheat on the MSU tests by specifying GOP lengths of 500 frames.

    Here's the reality, P and B frames by definition are based on I frames, it's to your benefit to have very quality I frames and it's to your benefit to have as many as possible, I typically like to have a GOP length of half frame rate. The added benefit of using such a short GOP is that you don't get frame pulsing (I have noticed that x264's quality tends to degrade as the GOP progresses) and you eliminate the need to use scene cut.

    We can continue this discussion tomorrow, I have to get to work. In the meantime try some short GOP bit rate based encodes, you may like the results. Of course if you absolutely must play around with quantizers maybe try changing pbratio and ipratio settings, can't stand the defaults anyway.
    Quote Quote  
Visit our sponsor! Try DVDFab and backup Blu-rays!