![]() The bitrate that was selected during the first pass was 155kbps. It is in two-pass mode, having already done the first pass. I would like to control the bitrate myself. Overriding user-specified value." It then proceeds to average about 1,200kbps, predicting 200MB of video data. Minimum possible bitrate for the clip is 500289 kbps. This is about 155kbps, right? When I start the encode, VirtualDub complains that "Specified bitrate is too low for this clip. GKnot doesn't work well for small output files so I am trying to make around 50~60 megs for video. #AVIDEMUX BITRATE TOO LOW 1080P#I think 250 is about the highest I'd use for most 1080p encoding, grainy or otherwise.Clip is 1419 seconds long, 704x480 as an AviSynth script produced by GKnot. I think the highest -nr-inter I've ever found useful was 750, and that was with some edge-case crazy content. Using a -nr-intra at 25-50% the -nr-inter value can help stabilize things somewhat. Which means it filters out small sharp details that vary from the pixels it predicts from. The -nr-inter is essentially an adaptive deadzone for high frequency coefficients in predicted blocks. Comparing 50 to 5 is pretty different! If you are combining -tune grain with -nr-inter 2000, I'd absolutely expect to see the "frozen grain" you describe. X264's -nr and x265's -nr-inter are the same core algorithm underneath and use the same scale (x264 doesn't have a -nr-intra equivalent). Some more notes looking over your bitrate comparisons It's come a long way in a relatively short period of time and much of the guidance and opinion appears to apply to older builds.Įdit: I've not included screenshots as I believe this might have been the reason the previous thread (with about eight screenshots) was not allowed.Įdit2: Included screenshots and basic information.Įdit3: Updated top of post to reflect new encodes and screenshots I hope this can lead to a discussion about the state of grain retention with x265 in 2021. I've read threads where it's stated that -tune grain isn't effective, but without an explanation. The grain on x265 appears to be static, and tuning for grain seems to be counterproductive. What I'm trying to understand, and I have read many, many threads, is why x265 appears to have such a problem with grain - even with a 10mbps 3-pass encode. pass 2 -bitrate 4500 -preset slow -output-depth 10 -profile main10 -rd 5 -psy-rd 2.15 -no-rect -aq-strength 0.6 -qcomp 0.65 -crf-max 0 -ipratio 1.35 -pbratio 1.25 -no-cutree -subme 4 -weightb -bframes 6 -rc-lookahead 30 -lookahead-slices 3 -colorprim bt709 -colormatrix bt709 -transfer bt709 -range limited -deblock -3:-3 I have lost many of the logs - and please ignore the () after -x265 as that's for my own sanity to try and make sure the information is correct. One of the CRF files has a bitrate of over 8mbps (x265) and is OK, but also very large. NOTE: These are 2-pass where stated, or CRF. I did create a different thread with screenshots, but it went to moderation and was never seen again (I don't believe it broke the rules at all, as I read each one - I've not received a message or notification about the thread so assume it has been lost).įrom testing, I've found (perceived rating out of 10): Sensible flags, such as veryslow for x264 and tuning for grain, and not tuning for grain on x265 but using slow and changing options manually that should preserve more grain, but with speed optimisations (just to get a rough idea of the output). All encodes were 10 bit to create a level playing field (as much as possible). I have done this to see what sort of difference it makes to the grain quality (I apologise if that doesn't make sense to anyone else).įor creating a 'perceived rating', I tested scenes with motion, darkness, detail, edge detail (plants in the corner), and other small details. However, I have played around with heavy noise removal using x265 and x264 built-in noise reduction. I've spent about 80 hours reading threads on doom9 the x265 documentation over a two week period. The aim of my experiment is to keep the grain, or as much of it as possible - or perceivably possible -, for the bitrate allocated. I've spent about 30 hours testing the same four minute clip of a very grainy source using 2-pass 4,500 kbps to control for size and bitrate (for comparisons), as well as a couple of CRF encodes thrown in to see what bitrate would be required (for x265). ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |