![]() You can enable the PMD denoise to help on noisy sources without destroying the picture quality. I usually go CQP-24 for most of my encodes and that gets me files from 7GB (upscaled Animation) to 35GB (4K heavy grain catalog titles). StaxRip spits out a smaller file in a few minutes. Once that's done, you crop to suit, pick which audio tracks and subtitles get re-encoded or muxed and hit next. I feed my HDR MKVs into StaxRip and it splits out all of the video, audio, and subtitle tracks into individual files. The application uses NVENC which you can also call from a command line without StaxRip. I get a 4K disc re-encoded in about 60-90 minutes on a RTX2070. It's a little more complex than Handbrake but it works with NVENC x265 in 10-bit. If you can invest in storage to keep the untouched files it will probably pay off in the long run. I found that as time went by I ended up having to go back and rip films again later once I'd invested in more storage, particularly as the quality or encoded files became problematic as other hardware got upgraded. ![]() ![]() I have 37T of drive space now used for my video and music ![]() a compressed (of a already compressed) source. I personally would rather have the larger, untouched movie vs. Hard drives are not that expensive nowdays. I've since realized that it's not worth the time to re-encode. I used to worry about space, and would use Handbrake to help save space. Is there any other software I could use as an alternative? Or do I just need to leave the video files as is? Usually with 1080p videos I re-encode them to make them smaller, but from what I've seen I can't use handbrake because it has an 8-bit internal pipeline. So in the case of high core CPUs the general consensus is to do two encodes at once, so you're more efficiently using the entire processor per unit of time, and there's no way you'd be devoting "too many" threads to a single encode.I recently got a bunch of 4k HDR movies and after ripping them my 1TB drive is about full. ![]() When using handbrake there's a muxing thread, a sound thread, a decode thread, a thread for each filter you have turned on, etc (the verbose logging option will tell you exactly how many are in use.) So for everything except the 1950x in this example, you're not going to go above the "cutoff" number, and you'll probably find in the 1950x's case you can't get all the cores to 100% because one of the single-thread processes is bottlenecking you (probably the sound thread). Now keep in mind that's literally just talking about encode threads. (As you can see this is really only a number you'd care about if you're encoding DVD or 720p level content.) So ideally with 1080p you'd want no more than 22 encode threads, for 4K it would be 44, etc. I've always been told to keep (vertical resolution of video) / (number of threads) to be absolutely above 30 and ideally above 50. Below that, _technically_ there's still some quality falloff between (say) six encode threads and two encode threads, but the difference is generally agreed to be negligible. Number of encode threads matter (in h.264 at least) when you start to get above 16. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |