VideoHelp Forum
+ Reply to Thread
Page 2 of 2
FirstFirst 1 2
Results 31 to 51 of 51
Thread
  1. Originally Posted by Selur View Post
    1st: using 1pass crf still only makes sense if you are not aiming for a specific file size.
    I am aiming for a specific file size and still use CRF because of its superior quality. I also have OCD.

    Originally Posted by Selur View Post
    2nd: SSIM is problematic if psychovisual enhancements are activated.
    That's because psychovisual enhancement makes the video worse. Nobody sensible uses it.

    Originally Posted by Selur View Post
    -> the argument about wasted time is not really interesting since the two methods aim for different goals
    We're discussing quality, regardless how negligent it may be.

    Originally Posted by Selur View Post
    At least for normal footage (movie like content, commercials&co; straight from the camera or out of the NLE tools) I never managed to get a comparison together that shows that 1pass crf is better at the same size as a 2pass encode. (1st make the crf encode, than the 2pass encode; for both passes make sure to have vbv enabled, since at least for me content needs to be vbv compliant to specific profiles&levels, most of the time high@4.1 or high10@4.1 is fine)
    No can't do, I always aim for maximization, not compliance.

    Originally Posted by Selur View Post
    If someone has a example for 1pass crf being better than 2pass with the same settings and the same file size, please share it.
    Okay, send me a relatively linear video clip (cartoon/anime/2D video game), make sure it's high quality and not a macroblocked MPEG2 mess of shit and I might produce a viable comparison.
    Quote Quote  
  2. Okay, send me a relatively linear video clip (cartoon/anime/2D video game), make sure it's high quality and not a macroblocked MPEG2 mess of shit and I might produce a viable comparison.
    I would like to, problem is that I do not have a clip that would match your requirements. (+ I'm not sure how to produce one since I never really looked into the production of such material,..)
    Quote Quote  
  3. You don't have to "produce" one yourself, just copy 60 seconds from a Blu-ray or something.
    Quote Quote  
  4. 1080p Trailer of 'Superman vs. The Elite' should than match your requirements.
    Quote Quote  
  5. Hmm. The CRF and 2-pass encodes of the Superman trailer are 9964 and 9968 KB respectively, 848x480 resized from 720p source you provided. SSIM's are 0.99403 and 0.99390.

    The CRF encode is higher quality but it's very negligible and not noticeable. The only immediate frame where I notice the difference is this one. The edge of that character's hair is blocky and smeared in the 2-pass encode while the CRF encode doesn't have this problem.

    I can make excuses all day about that source not being noise-free and linear enough but I realize that 99.99% of all videos on the net are not game replays that benefit most from motion vectors.

    I withdraw my claim. CRF is at worst the same quality as 2-pass and not noticeably better on average.
    Image Attached Thumbnails Click image for larger version

Name:	2P.PNG
Views:	368
Size:	154.1 KB
ID:	12013  

    Click image for larger version

Name:	CRF.PNG
Views:	444
Size:	157.0 KB
ID:	12014  

    Quote Quote  
  6. I withdraw my claim. CRF is at worst the same quality as 2-pass and not noticeably better on average.
    + I'm quite sure there is also a frame that has a portion that looks better in the 2pass encode

    -> I would agree with:

    'For the same size 1pass crf and 2pass bitrate produce the same perceivable quality.'

    Cu Selur
    Quote Quote  
  7. There are more 'better' frames on the CRF encode than 2-pass, as confirmed by the higher SSIM value. We can argue about the reliability of SSIM but it's very consistent with noiseless, low-complexity videos. But again, it is minimal.

    'For the same size 1pass crf and 2pass bitrate produce the same perceivable quality.'
    More or less correct. They have different advantages. 2pass knows the complexity of every frame in advance thanks to the first pass, and CRF mode has more freedom to use flexible vectors to better capture motion. This is most pronounced on perfectly clean videos like screencaps of 2D video games, the only case where CRF is visibly superior, but even then it is more or less minimal.
    Quote Quote  
  8. There are more 'better' frames on the CRF encode than 2-pass, as confirmed by the higher SSIM value.
    didn't know you also looked at the SSIM values of every frame, because the SSIM x264 offers normally is a global SSIM and therefore a sum of the SSIM values of all the frames,...
    Quote Quote  
  9. I didn't grab the SSIM value from x264, I got it from MSU Video Quality Measurement using SSIM (precise). It is the average value, which CRF got 13 points higher. The difference of those two screenshots I posted is only 2 points, so you are right not only that some frames are better or worse but many parts of the frame have variable quality differences.
    Quote Quote  
  10. btw. while at it did anyone ever check how much the ssim values fluctuate if one uses '--non-deterministic' ?

    Cu Selur
    Quote Quote  
  11. Originally Posted by Mephesto View Post
    Originally Posted by poisondeathray View Post
    Originally Posted by Mephesto View Post
    CRF is better quality at the same file size than 2pass mode. Experiments confirmed it.

    No

    It can be very similar, sometimes worse in some scenes, sometimes better, but rarely is it overall "better"
    Not true, it is always better at the same filesize with the same settings. The difference is negligible on photographic videos (+50 SSIM) but somewhat noticeably better on low-complexity videos like cartoons and game replays (+300 SSIM.)

    I've tested this time and time again. It is difficult to make the file sizes identical which is why I made the CRF videos be slightly smaller than the 2pass and STILL the SSIM was higher.

    The thing is, when you seek an arbitrary bitrate like 2pass mode was designed for, you do it at the expense of encoding freedom and lose lots of opportunities for better compression. This is alleviated by the first pass which at least makes flexible evaluation of different scenes possible and minimizes the damage of an arbitrary bitrate.

    But this still destroys the superior motion vectors that are more free-flowing on CRF mode.

    Even if the difference is negligible, the time wasted with the first pass isn't.

    The difference is negligible, and the time wasted in the first pass might depend on your goals. If you have to re-encode a CRF encoded video 5-7 times to fit on a blu-ray, then the time wasted using CRF is much worse

    I've too have literally done 100's (probably 1000's) of comparisions, and posted some before

    And since when was SSIM a perfect indicator of "quality?"

    Have you seen a --tune ssim or --tune psnr encode? quality is usually visibly worse on normal encodes, yet the values indicate "better" quality. Note psy is deactivated when you use --tune ssim, and AQ is deactivated when you use --tune PSNR

    The reason why "cartoons" and smooth animation show a larger difference (with SSIM or PSNR) is that grain and noise tend to produce lower results.

    If you claimed that CRF generally produces a negligibly higher SSIM value than 2pass settings at identical bitrates - then I would agree on some content. But negligibly higher SSIM does not necessarily equate to visibly higher quality - in fact it often indicates lower quality. Only when the deviation is large, is it a more reliable indicator of "quality"
    Quote Quote  
  12. I can't find the previous discussion threads, but I had this illustrative example saved on HDD somewhere. It was a comparison a few years ago with x264, mainconcept's encoder.

    It's a live action example (not animation, but for the same reasons, CGI , PIXAR type animation also tend to "behave" like live action footage in terms of PSNR and SSIM evaluations)

    x264 used more normal settings for visual quality , I can't recall the exact settings ( but not --tune SSIM) , and here is a typical frame (note this is a frame SSIM value, not global - you can run it through MSU's tool as the screenshots are saved as .bmp)

    x264 SSIM 0.9841
    MCR SSIM 0.9854

    So SSIM values indicate Mainconcept should produce better result on this frame right?? Well download the zip file and look at the differences in details in the face and skin comaring to the original. Huge differences in quality. You don't even have to pixel peep like your animation example. Notice how it's all "smoothed" away in the higher SSIM encode. This is typical of what happens when encoders are developed for SSIM or PSNR - you get plasticky looking results - just like Mainconcep'ts encoder. This might be more forgiving on simple animated toon content , but results in banding along gradients especially in dark areas - so parts of some frames might look better in quality, but dark backgrounds and gradients tend to look worse

    I have many more examples, but it's just meant to illustrate some potential issues with relying on SSIM
    Image Attached Files
    Quote Quote  
  13. If you have to re-encode a CRF encoded video 5-7 times to fit on a blu-ray, then the time wasted using CRF is much worse
    I often have to reencode twice with 2pass even, as it diverges from the target bitrate by 2-3%.

    And since when was SSIM a perfect indicator of "quality?"
    It is very consistent when tested on noise-free videos. I remember those pictures and vaguely recall the discussion we already had a few years ago about this. In my own tests (mostly done with noiseless videos) I have come across values as low as 0.89000 that didn't look so bad, and values as high as 0.98400 that were complete zit-spooge, so by no means do I proclaim SSIM is perfect. CRF does make more economic use of motion vectors than 2pass mode which is most noticeable on carefully-chosen content, though. This is fact.

    Out of interest, do you have any other, more extreme examples of SSIM failure than those weak screencaps you posted right now? I could argue that the MC encoder was better quality because it omitted more noise, providing a clearer picture and thus the SSIM value was consistent.
    Quote Quote  
  14. Originally Posted by Mephesto View Post
    If you have to re-encode a CRF encoded video 5-7 times to fit on a blu-ray, then the time wasted using CRF is much worse
    I often have to reencode twice with 2pass even, as it diverges from the target bitrate by 2-3%.

    And since when was SSIM a perfect indicator of "quality?"
    It is very consistent when tested on noise-free videos. I remember those pictures and vaguely recall the discussion we already had a few years ago about this. In my own tests (mostly done with noiseless videos) I have come across values as low as 0.89000 that didn't look so bad, and values as high as 0.98400 that were complete zit-spooge, so by no means do I proclaim SSIM is perfect. CRF does make more economic use of motion vectors than 2pass mode which is most noticeable on carefully-chosen content, though. This is fact.
    I agree with the comments CRF encoding in general, but the wording in the earlier comments needs to be clarified - and broad based generalizations should be avoided

    I stick by what I said earlier:

    It can be very similar, sometimes worse in some scenes, sometimes better, but rarely is it overall "better"


    Out of interest, do you have any other, more extreme examples of SSIM failure than those weak screencaps you posted right now? I could argue that the MC encoder was better quality because it omitted more noise, providing a clearer picture and thus the SSIM value was consistent.
    I know you're joking, but some readers might not know that , so I'll clarify - The goal of an encoder is to most faithfully reproduce what is given to it. It's not the job of an encoder to "denoise". That's a preprocessing job.



    (And I hope you're not encoding cartoons with --tune ssim or using --no-psy)
    Quote Quote  
  15. I often have to reencode twice with 2pass even, as it diverges from the target bitrate by 2-3%.
    see: http://forum.doom9.org/showthread.php?t=155205
    for me it helped, to lower qcomp to 0.5, but Dark Shikari wrote:
    Lowering qcomp should not affect this at all. If it does, it's sheer dumb luck. It's no different from any other trivial modification to settings -- it's rerolling the dice on something that is 100% random.
    -> seems like at least sometimes I have 'sheer dumb luck' -> might be worth a try
    Quote Quote  
  16. I know you're joking, but some readers might not know that , so I'll clarify - The goal of an encoder is to most faithfully reproduce what is given to it. It's not the job of an encoder to "denoise". That's a preprocessing job.
    Disagree, the job of a lossy encoder is to reinterpret content in such a way that it saves space without removing important, perceptible detail. We are moving towards parametric encoding techniques which may produce artifacts that are noticeable but not annoying. Compressing film noise by encoding it as a 1-byte PRNG value will be 0% faithful by your definition, yet the human eyes wont care.

    (And I hope you're not encoding cartoons with --tune ssim or using --no-psy)
    --no-psy yes, --tune ssim no. I use SSIM as a second-hand guide, but mainly use the MSUVQMT because I love how it lets me examine individual frames guided by the SSIM histogram. As I said, I've had videos with very low SSIM values that weren't that bad, and others I had to continue reencoding because even 0.98900 values were visibly substandard quality.

    @Selur
    The divergence is at a consistent 2.2% with my encoding settings, so I just multiply my intended bitrate by 1.0213852525127186995905199156223 to get it to end up with the real bitrate. 1.016 if I'm using 10+ ref frames. It depends on the settings.
    Quote Quote  
  17. "The divergence is at a consistent 2.2%"
    -> sounds more like a wrong target bitrate,.. (i.e. because the container overhead wasn't calculated properly)
    Quote Quote  
  18. Originally Posted by Mephesto View Post
    I know you're joking, but some readers might not know that , so I'll clarify - The goal of an encoder is to most faithfully reproduce what is given to it. It's not the job of an encoder to "denoise". That's a preprocessing job.
    Disagree, the job of a lossy encoder is to reinterpret content in such a way that it saves space without removing important, perceptible detail. We are moving towards parametric encoding techniques which may produce artifacts that are noticeable but not annoying. Compressing film noise by encoding it as a 1-byte PRNG value will be 0% faithful by your definition, yet the human eyes wont care.
    Yes, a lossy encoder. And a "perfect" lossy encoder would approach lossless results, correct?

    But would human eyes care about the difference in the screenshots provided earlier? I certainly do. Do people always look that plasticky in real life ? This is a real encoding situation. The problem is an encoder cannot distinguish effectively between "film noise" and "wanted grain" or even wanted fine details

    If you've followed the development of x264 over the years, before AQ and psy were introduced, it was blasted for producing exactly that - "plasicky" lifeless results. In fact the old x264 encodes look surpisingly similar to mainconcept encodes and RMVB. No detail.

    If you follow anime encoder forums, many of the problems encountered with animation encoding is excessive removal of noise with resulting banding, especially in dark scenes. Low levels of Psy , AQ and grain retention patches are actually ways of dealing with this , along with adding back noise and dithering for preprocessing. There is a reason why --tune animation has low levels of psy and AQ instead of --no psy. With --no psy it's almost impossible to retain dithering results
    Quote Quote  
  19. Nope, 2.2% of 700 MB would be 15 MB of overhead, even H264 in an AVI container doesn't have that much.
    Quote Quote  
  20. but for i.e. m2ts 2.2% isn't much at all for a 700MB file,...
    Quote Quote  
  21. Originally Posted by poisondeathray View Post
    Yes, a lossy encoder. And a "perfect" lossy encoder would approach lossless results, correct?
    With a high bitrate, yup. See below.

    Originally Posted by poisondeathray View Post
    But would human eyes care about the difference in the screenshots provided earlier? I certainly do. Do people always look that plasticky in real life ? This is a real encoding situation.
    Do people always look that grainy in real life? It's a two way street. I don't disagree with your point, but I was saying that your screenshot example doesn't get it across as strongly as a more extreme example could. Noise interferes with subjective quality analysis because human eyes don't care if the noise is altered, different or even not there at all.

    Many of my encodes (which are denoised but some fast-paced scenes are unaffected) that I analyze with MSU often have low peaks that immediately get my attention, and it turns out the reason they got such a low value was because the fine noise in the otherwise blurry scene is gone. The other noiseless scenes with close-ups of human skin did not have loss of detail, so why should I care that the low peaks did? Am I gonna increase the bitrate by 50% just to keep momentary noise?

    Originally Posted by poisondeathray View Post
    The problem is an encoder cannot distinguish effectively between "film noise" and "wanted grain" or even wanted fine details
    H.264 is fairly intelligent in this department even if not perfect.

    Originally Posted by poisondeathray View Post
    If you've followed the development of x264 over the years, before AQ and psy were introduced, it was blasted for producing exactly that - "plasicky" lifeless results. In fact the old x264 encodes look surpisingly similar to mainconcept encodes and RMVB. No detail.
    Noise adds considerable entropy and wastes bitrate. If they got plasticky results, perhaps they should've stopped using pathetically low bitrates. All --psy does is scuzz up the edges and make the video look worse.

    Originally Posted by poisondeathray View Post
    If you follow anime encoder forums
    I don't, thank god.

    many of the problems encountered with animation encoding is excessive removal of noise with resulting banding, especially in dark scenes.
    That's easily fixed by post-processing in FFDShow. There's debanding and adding noise for all those autistic turds on Anime forums who talk about noisy videos feeling "warmer", like their pillows on a lonely night.

    Low levels of Psy , AQ and grain retention patches are actually ways of dealing with this , along with adding back noise and dithering for preprocessing. There is a reason why --tune animation has low levels of psy and AQ instead of --no psy. With --no psy it's almost impossible to retain dithering results
    Retaining gradients to that level requires ridiculously high bitrates, it's much cheaper to use post-processing. :/
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!