I am aiming for a specific file size and still use CRF because of its superior quality. I also have OCD.
That's because psychovisual enhancement makes the video worse. Nobody sensible uses it.
We're discussing quality, regardless how negligent it may be.
No can't do, I always aim for maximization, not compliance.
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.
Try StreamFab Downloader and download from Netflix, Amazon, Youtube! Or Try DVDFab and copy Blu-rays! or rip iTunes movies!
+ Reply to Thread
Results 31 to 51 of 51
Thread
-
-
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.
-
You don't have to "produce" one yourself, just copy 60 seconds from a Blu-ray or something.
-
1080p Trailer of 'Superman vs. The Elite' should than match your requirements.
-
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. -
I withdraw my claim. CRF is at worst the same quality as 2-pass and not noticeably better on average.
-> I would agree with:
'For the same size 1pass crf and 2pass bitrate produce the same perceivable quality.'
Cu Selur -
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.' -
There are more 'better' frames on the CRF encode than 2-pass, as confirmed by the higher SSIM value.
-
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.
-
btw. while at it did anyone ever check how much the ssim values fluctuate if one uses '--non-deterministic' ?
Cu Selur -
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" -
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 -
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
And since when was SSIM a perfect indicator of "quality?"
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 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.
(And I hope you're not encoding cartoons with --tune ssim or using --no-psy) -
I often have to reencode twice with 2pass even, as it diverges from the target bitrate by 2-3%.
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. -
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)
@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. -
"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) -
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 -
Nope, 2.2% of 700 MB would be 15 MB of overhead, even H264 in an AVI container doesn't have that much.
-
With a high bitrate, yup. See below.
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?
H.264 is fairly intelligent in this department even if not perfect.
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.
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.
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
Similar Threads
-
Virtual Dub 1st & 2nd Pass Encoding
By OrchestraAndChoir in forum Video ConversionReplies: 10Last Post: 22nd Jul 2012, 08:20 -
x264 encoding occurs too fast in pass 1
By codemaster in forum DVD RippingReplies: 5Last Post: 21st Sep 2011, 22:28 -
Technical Query Re Reading of 1st pass stats during second pass xvid encode
By onesikgypo in forum Video ConversionReplies: 1Last Post: 13th Mar 2011, 07:59 -
Removing subtitles, running 1st pass again?
By moviebuff2 in forum Newbie / General discussionsReplies: 1Last Post: 28th Dec 2007, 07:20 -
1st time on linux: looking to convert my DVDs to x264
By bgbop15 in forum LinuxReplies: 3Last Post: 19th Jul 2007, 14:56