VideoHelp Forum

Try DVDFab and download streaming video, copy, convert or make Blu-rays,DVDs! Download free trial !
+ Reply to Thread
Results 1 to 26 of 26
Thread
  1. Member
    Join Date
    Jun 2007
    Location
    United States
    Search Comp PM
    Well I just recently ran across this program, and I noticed with this program, encoding to x265. I get better FPS, and higher CPU usage, during encodes. Which helps speed of encoding time. With that said.. it has me curious what's this program doing better than others to speed things up?

    I have tried a couple other programs that can also do x265 encoding, using the same video files, same x265 preset. RipBot264 without question, encodes faster. With that, some of the other programs I do like their menu's a bit better, and some of their options as well. Still being able to cut down on encoding time is important. Currently RipBot264 seems to load the CPU better with x265, which in return gives the encode a higher FPS average. This is more obvious with non 4k resolution encodes, aka 1080p, and such. As other programs seem to barely put any load on the CPU, with lower resolution videos.

    So anyone have an ideal what could be causing this to be better with this program? Is there a default option this program is using with x265, that's doing this? If so, anyone have an ideal what it is? I would love to know the reason for this.
    Quote Quote  
  2. Any number of things could be at play here, different x265 version, different flags passed to the compiler during the build process, different decoder, maybe some are using x265 from with ffmpeg or avconv vs using x265 directly and piping the decoded frames to it, how I/O is handled by the app.

    There's all sort of things that can affect encoding speed, the question is how much of a speed difference are you seeing.

    There is also the possibility that RipBot264 is changing the default cpu priority behind the scenes.

    Just some thoughts.
    Quote Quote  
  3. Member
    Join Date
    Jun 2007
    Location
    United States
    Search Comp PM
    Well today I tested the same x264 file 720p resolution no change to it, which had around a 90 minute runtime. With RipBot264, using default x265 options except changing the preset to slow, and using CQ at 20. Encoding took around 36 minutes total. So FPS averaged near 70. CPU usage around 80-85%, on my Ryzen 3950x.

    I run this same test on handbrake. I averaged around 25-30fps, and well over an hour of encoding time. CPU usage in the 20-30% range max. Overall a "big" difference between the two.

    I'm not advanced enough to dig thru how each one is doing this process, that's why I come here, to see if anyone else has an ideal on what could be going on. Because as I mentioned before some of the other programs, I like how the settings, and such, are setup. I would love to use one of the other programs, with the speed in which RipBot264 is encoding x265 on my Ryzen 3950x.

    Anyways if anyone who reads this post, has the time, try setting up RipBot264, and running a test as well. I am sure you will see the difference between it, and other programs using x265. If I had a guess, I would think RipBot264, is using a "advanced x265 option" as a default, and it's increasing my CPU's workload, speeding up the encoding time. Currently most programs that do x265 encoding, when working with 1080p/720p video files. The CPU is far from being maxed out, which overall keeps the encoding FPS low, slowing down the whole process. RipBot264 is somehow using 2-3x overall CPU during these encodes.
    Quote Quote  
  4. Look at the metadata and see what's different in the encoding settings. MediaInfo can show you that. For example:

    Code:
    Video
    ID                                       : 1
    Format                                   : HEVC
    Format/Info                              : High Efficiency Video Coding
    Format profile                           : Main@L3.1@Main
    Codec ID                                 : V_MPEGH/ISO/HEVC
    Duration                                 : 55 min 32 s
    Width                                    : 1 280 pixels
    Height                                   : 640 pixels
    Display aspect ratio                     : 2.000
    Frame rate mode                          : Variable
    Original frame rate                      : 25.000 FPS
    Color space                              : YUV
    Chroma subsampling                       : 4:2:0
    Bit depth                                : 8 bits
    Title                                    : MiNX - Small HD episodes
    Writing library                          : x265 0.0:[Linux][GCC 6.3.0][64 bit] 8bit+10bit+12bit
    Encoding settings                        : wpp / ctu=64 / min-cu-size=8 / max-tu-size=32 / tu-intra-depth=1 / tu-inter-depth=1 / me=1 / subme=2 / merange=57 / no-rect / no-amp / max-merge=2 / temporal-mvp / early-skip / rskip / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / fast-intra / open-gop / no-temporal-layers / interlace=0 / keyint=250 / min-keyint=25 / scenecut=40 / rc-lookahead=15 / lookahead-slices=0 / bframes=4 / bframe-bias=0 / b-adapt=0 / ref=2 / limit-refs=3 / no-limit-modes / weightp / no-weightb / aq-mode=1 / qg-size=32 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=2 / psy-rd=2.00 / rdoq-level=0 / psy-rdoq=0.00 / log2-max-poc-lsb=8 / no-rd-refine / signhide / deblock=0:0 / sao / no-sao-non-deblock / b-pyramid / cutree / no-intra-refresh / rc=crf / crf=24.1 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ipratio=1.40 / pbratio=1.30
    Language                                 : English
    Default                                  : Yes
    Forced                                   : No
    Quote Quote  
  5. Originally Posted by cowboysroy31 View Post
    Well today I tested the same x264 file 720p resolution no change to it, which had around a 90 minute runtime. With RipBot264, using default x265 options except changing the preset to slow, and using CQ at 20. Encoding took around 36 minutes total. So FPS averaged near 70. CPU usage around 80-85%, on my Ryzen 3950x.

    I run this same test on handbrake. I averaged around 25-30fps, and well over an hour of encoding time. CPU usage in the 20-30% max. Overall a "big" difference between the two.

    I'm not advanced enough to dig thru how each one is doing this process, that's why I come here, to see if anyone else has an ideal on what could be going on. Because as I mentioned before some of the other programs, I like how the settings, and such, are setup. I would love to use one of the other programs, with the speed in which RipBot264 is encoding x265 on my Ryzen 3950x.

    Anyways if anyone who reads this post, has the time, try setting up RipBot264, and running a test as well. I am sure you will see the difference between it, and other programs using x265. If I had a guess, I would think RipBot264, is using a "advanced x265 option" as a default, and it's increasing my CPU's workload, speeding up the encoding time. Currently most programs that do x265 encoding, when working with 1080p/720p video files. The CPU is far from being maxed out, which overall keeps the encoding FPS low, slowing down the whole process. RipBot264 is somehow using 2-3x overall CPU during these encodes.
    I downloaded the source for Hand Brake and I downloaded RipBot, the former has the various encoders "built in" while RipBot has all the encoders as separately compiled tools; HB is more of an all-in-one tool written in C while RipBot is just a simple GUI written in Delphi/Object Pascal.

    Lastly, there is also the possibility that you have inadvertently had one of HB's filters enabled, there's a few of them enabled by default.
    Quote Quote  
  6. Member
    Join Date
    Jun 2007
    Location
    United States
    Search Comp PM
    Well I deleted the video I ran with handbrake. But I am running another encode to see what it will show once done. Anyways I pulled the encoding settings info from the video RipBot264 encoded. A lot of this is blah to me. But figured I would post it, as I feel like something within the "advanced settings" is what's speeding up the encoding process.

    The handbrake encode I have going as I type this, is only using between 20-25% CPU. Which is without question, why the encode is going much slower.. I just got to figure out what setting RipBot264 is using, to increase the workload on my CPU.

    Here's the settings RipBot264 used
    Code:
    Encoding settings: cpuid=1111039 / frame-threads=5 / numa-pools=32 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1280x640 / interlace=0 / total-frames=133070 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=4 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=24 / keyint=240 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=25 / lookahead-slices=0 / scenecut=40 / hist-scenecut=0 / radl=0 / no-splice / no-intra-refresh / ctu=16 / min-cu-size=8 / rect / no-amp / max-tu-size=16 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=2 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=3 / limit-refs=3 / limit-modes / me=3 / subme=3 / merange=9 / temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=4 / selective-sao=4 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=1.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=20.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=2 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=16 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=1 / transfer=1 / colormatrix=1 / chromaloc=0 / display-window=0 / cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / hist-threshold=0.01 / no-opt-cu-delta-qp / no-aq-motion / no-hdr10 / no-hdr10-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=0 / analysis-save-reuse-level=0 / analysis-load-reuse-level=0 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00 / no-scenecut-aware-qpconformance-window-offsets / right=0 / bottom=0
    Quote Quote  
  7. Member
    Join Date
    Jun 2007
    Location
    United States
    Search Comp PM
    Originally Posted by sophisticles View Post
    Lastly, there is also the possibility that you have inadvertently had one of HB's filters enabled, there's a few of them enabled by default.
    Well I only changed the couple settings I mentioned above, and the rest was left as default. Overall I would love to pin point whatever RipBot264 is doing to push my CPU. As that's without question the reason behind it encoding much faster.
    Quote Quote  
  8. Your cpu has a lot of cores and specific steps have to be taken to ensure they are adequately loaded.

    To encode real slow, try:
    numa-pools=1
    frame threads=1
    Quote Quote  
  9. Originally Posted by cowboysroy31 View Post
    The handbrake encode I have going as I type this, is only using between 20-25% CPU. Which is without question, why the encode is going much slower.. I just got to figure out what setting RipBot264 is using, to increase the workload on my CPU.
    You are very mistaken with this assumption, just because a cpu is being loaded up to 100% vs 25% does not mean that it will run that task 4 times as fast. A classic example is x264, run a 1080p encode using x264+ultrafast and it won't even load a dual core i3 7100 past 50% ( I have tried it), run a 4k encode with x264+placebo and it will load up an 8C/16T cpu no problem, yet the former encode will be many times faster.

    Another example, download the Tears of Steel movie, in 2 versions, the 13Gb JPEG2000 mxf encapsulated version and the 66Gb Y4M uncompressed version; try to encode the first with x265+medium+some filters and it will load up a dual Xeon server, try to encode the second with x264+medium+no filters and you won't even load up 6C/12T Ryzen.

    Stop trying to predict encoding speed based on how much cpu usage there is, one has nothing to do with the other.
    Quote Quote  
  10. You might be source limited. One program may be using software to decode the source, one using the graphics card's hardware. You haven't mentioned audio -- that could also be a problem. Some audio encoders are single threaded and could become a bottleneck.
    Quote Quote  
  11. Member
    Join Date
    Jun 2007
    Location
    United States
    Search Comp PM
    Originally Posted by butterw View Post
    Your cpu has a lot of cores and specific steps have to be taken to ensure they are adequately loaded.

    To encode real slow, try:
    numa-pools=1
    frame threads=1
    Yes using a super slow preset does help put more load on the CPU. However using medium/slow preset on x264, with 1080p/720p videos, keeps the load rather low on most programs. RipBot264 is doing a good job of still loading the CPU with x265 on these videos.

    Also looking over both HB, and RB264 encodes. They were both using numa-pools=32, and frame threads=5. So nothing in terms of them two settings is making any difference.
    Quote Quote  
  12. Member
    Join Date
    Jun 2007
    Location
    United States
    Search Comp PM
    Originally Posted by jagabo View Post
    You might be source limited. One program may be using software to decode the source, one using the graphics card's hardware. You haven't mentioned audio -- that could also be a problem. Some audio encoders are single threaded and could become a bottleneck.
    Well I will look at HB again later, at least with RB264, there's no kind of load on the GPU during the encoding process, it's strictly using CPU. I have direct copied the audio with RB264, and I will do it with HB later. However I am pretty positive, it will make no difference. Overall I appreciate the info.
    Quote Quote  
  13. Member ricardouk's Avatar
    Join Date
    Mar 2005
    Location
    Portugal
    Search Comp PM
    Hi, just did a quick test on my PC and got different results, converted a 30s 2.7k video with x265, 2 pass @10000Kbps, no audio, Main profile, encoder level 5.0., i disabled all the video filters in handbrake( it had automatically selected decomb but its not needed) no resizing on both.

    ripbot264 - 5m,40s
    handbrake - 6m,40s - (turbo first pass disabled)
    handbrake - 5m,50s - (turbo first pass enabled)


    Mediainfo report from Handbrake conversion
    Code:
    Video
    ID                             : 1
    Format                         : HEVC
    Format/Info                    : High Efficiency Video Coding
    Format profile                 : Main@L5@Main
    Codec ID                       : V_MPEGH/ISO/HEVC
    Duration                       : 32 s 65 ms
    Bit rate                       : 10.2 Mb/s
    Width                          : 2 720 pixels
    Height                         : 1 530 pixels
    Display aspect ratio           : 16:9
    Frame rate mode                : Constant
    Frame rate                     : 29.970 (30000/1001) FPS
    Color space                    : YUV
    Chroma subsampling             : 4:2:0
    Bit depth                      : 8 bits
    Bits/(Pixel*Frame)             : 0.082
    Stream size                    : 39.0 MiB (100%)
    Writing library                : x265 3.2+34-8e6db24c1517:[Windows][GCC 9.2.0][64 bit] 8bit+10bit+12bit
    Encoding settings              : cpuid=1064959 / frame-threads=2 / numa-pools=6 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=2720x1530 / interlace=0 / total-frames=961 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=30 / keyint=300 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=8 / scenecut=40 / hist-scenecut=0 / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=3 / limit-refs=1 / no-limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=3 / selective-sao=4 / early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=abr / bitrate=10000 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=2 / cplxblur=20.0 / qblur=0.5 / ipratio=1.40 / pbratio=1.30 / aq-mode=2 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=1 / transfer=1 / colormatrix=1 / chromaloc=0 / display-window=0 / cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / hist-threshold=0.01 / no-opt-cu-delta-qp / no-aq-motion / no-hdr10 / no-hdr10-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=0 / analysis-save-reuse-level=0 / analysis-load-reuse-level=0 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00 / no-scenecut-aware-qpconformance-window-offsets / right=0 / bottom=0
    Default                        : Yes
    Forced                         : No
    Color range                    : Limited
    Color primaries                : BT.709
    Transfer characteristics       : BT.709
    Matrix coefficients            : BT.709




    Mediainfo report from Handbrake conversion
    Code:
    Video
    ID                             : 1
    Format                         : HEVC
    Format/Info                    : High Efficiency Video Coding
    Format profile                 : Main@L5@Main
    Codec ID                       : V_MPEGH/ISO/HEVC
    Duration                       : 32 s 65 ms
    Bit rate                       : 10.0 Mb/s
    Width                          : 2 720 pixels
    Height                         : 1 530 pixels
    Display aspect ratio           : 16:9
    Frame rate mode                : Constant
    Frame rate                     : 29.970 (30000/1001) FPS
    Color space                    : YUV
    Chroma subsampling             : 4:2:0
    Bit depth                      : 8 bits
    Bits/(Pixel*Frame)             : 0.080
    Stream size                    : 38.4 MiB (98%)
    Writing library                : x265 3.2.1+1-b5c86a64bbbe:[Windows][GCC 9.2.0][64 bit] 8bit+10bit+12bit
    Encoding settings              : cpuid=1064959 / frame-threads=2 / numa-pools=6 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=2720x1530 / interlace=0 / total-frames=0 / level-idc=50 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=30 / keyint=300 / gop-lookahead=0 / bframes=4 / b-adapt=0 / b-pyramid / bframe-bias=0 / rc-lookahead=15 / lookahead-slices=8 / scenecut=40 / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=2 / limit-refs=3 / no-limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=2 / selective-sao=4 / no-early-skip / rskip / fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=abr / bitrate=10000 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=2 / cplxblur=20.0 / qblur=0.5 / ipratio=1.40 / pbratio=1.30 / aq-mode=2 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=1 / transfer=1 / colormatrix=1 / chromaloc=0 / display-window=0 / cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=5 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00
    Default                        : Yes
    Forced                         : No
    Color range                    : Limited
    Color primaries                : BT.709
    Transfer characteristics       : BT.709
    Matrix coefficients            : BT.709
    Last edited by ricardouk; 13th Aug 2020 at 18:39.
    I love it when a plan comes together!
    Quote Quote  
  14. If cowboysroy31 would post MediaInfo reports from the same conversion by each program we might gain some insight into why Handbrake is taking longer.
    Last edited by jagabo; 13th Aug 2020 at 18:18.
    Quote Quote  
  15. Member ricardouk's Avatar
    Join Date
    Mar 2005
    Location
    Portugal
    Search Comp PM
    Just noticed ripbot264 selected main 10bit profile instead of 8bit profile, redone the ripbot test(mediainfo report updated) and it took 1 minute less than before bringing it to the same "exact times" as handbrake with 1st pass turbo mode enabled, from my newbie point of view they both take the same time as long as you make sure to dig in the programs and make sure that all settings are the same and no unnecessary options are enabled.

    with the tests i found out that ripbot264 has gone totally portable and handbrake has 2 pass modes back!
    Last edited by ricardouk; 13th Aug 2020 at 20:08.
    I love it when a plan comes together!
    Quote Quote  
  16. Member
    Join Date
    Jun 2007
    Location
    United States
    Search Comp PM
    Originally Posted by jagabo View Post
    If cowboysroy31 would post MediaInfo reports from the same conversion by each program we might gain some insight into why Handbrake is taking longer.
    I will try to get that info posted by tomorrow morning. I mistakenly deleted both converted files, so I didn't have the media info data to post. I actually got the test done with RipBot264, however I am now onto the Handbrake encode, and it is gonna take a bit over 40 minutes to complete. Only took 18 minutes with RB264.

    I am using a 30 minute 1080p x265 video. I am still encoding it over to x265 using 8 bit(standard x265). I am using CQ at 20, with the preset at Slow. I removed the audio from the file. So it's strictly only video. I also went thru settings on both HB, and RB264. Made everything match as best as I could. Overall vanilla settings, besides what I listed above.

    I will post the MediaInfo data from both converted files in the morning. I can tell you both programs had matching priority from the CPU. I checked myself. During the RB264 encode, the CPU load averaged a bit over 80%, RB264 showed right at 40fps during the encode. Currently Handbrake is only showing a 15FPS average 12 minutes into the encode, CPU is showing around 25% load.
    Last edited by cowboysroy31; 13th Aug 2020 at 20:53.
    Quote Quote  
  17. Member
    Join Date
    Jun 2007
    Location
    United States
    Search Comp PM
    Originally Posted by ricardouk View Post
    Just noticed ripbot264 selected main 10bit profile instead of 8bit profile, redone the ripbot test(mediainfo report updated) and it took 1 minute less than before bringing it to the same "exact times" as handbrake with 1st pass turbo mode enabled, from my newbie point of view they both take the same time as long as you make sure to dig in the programs and make sure that all settings are the same and no unnecessary options are enabled.

    with the tests i found out that ripbot264 has gone totally portable and handbrake has 2 pass modes back!
    I am using CQ, so no 2 pass bitrate encode for me. However I have done a couple of them as well, still a pretty big difference, between Ripbot264, and Handbrake, for me. As I mentioned earlier in this thread. I am using a Ryzen 3950x, which is a 16 core/32 thread CPU. Overall I would of never made this thread, if i was only seeing a minute, or so, difference between both programs, in encode time.
    Quote Quote  
  18. Member
    Join Date
    Jun 2007
    Location
    United States
    Search Comp PM
    Well I am still awake, and moving around. The handbrake encode just finished a couple minutes ago. Anyways here's MediaInfo on both encodes.

    RipBot264 x265(standard 8 bit) Using CQ 20 with Slow Preset Encode time 18:00 CPU Load Average 80+
    Code:
    General
    Unique ID                                : 136852488135919773334341382151885266927 (0x66F4D49AC32C121316CF379D145F9FEF)
    Complete name                            : C:\30 minute test 1080p RB264.mkv
    Format                                   : Matroska
    Format version                           : Version 4 / Version 2
    File size                                : 616 MiB
    Duration                                 : 30 min 0 s
    Overall bit rate                         : 2 870 kb/s
    Movie name                               : 30 minute test 1080p RB264
    Encoded date                             : UTC 2020-08-14 01:30:46
    Writing application                      : mkvmerge v46.0.0 ('No Deeper Escape') 64-bit
    Writing library                          : libebml v1.3.10 + libmatroska v1.5.2
    
    Video
    ID                                       : 1
    Format                                   : HEVC
    Format/Info                              : High Efficiency Video Coding
    Format profile                           : Main@L4@Main
    Codec ID                                 : V_MPEGH/ISO/HEVC
    Duration                                 : 30 min 0 s
    Bit rate                                 : 2 868 kb/s
    Width                                    : 1 920 pixels
    Height                                   : 800 pixels
    Display aspect ratio                     : 2.40:1
    Frame rate mode                          : Constant
    Frame rate                               : 23.976 (24000/1001) FPS
    Color space                              : YUV
    Chroma subsampling                       : 4:2:0
    Bit depth                                : 8 bits
    Bits/(Pixel*Frame)                       : 0.078
    Stream size                              : 615 MiB (100%)
    Writing library                          : x265 3.3+1-g396395b2b:[Windows][GCC 9.2.0][64 bit] 8bit+10bit+12bit
    Encoding settings                        : cpuid=1111039 / frame-threads=5 / numa-pools=32 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x800 / interlace=0 / total-frames=43158 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=4 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=24 / keyint=240 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=25 / lookahead-slices=4 / scenecut=40 / hist-scenecut=0 / radl=0 / no-splice / no-intra-refresh / ctu=32 / min-cu-size=8 / rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=2 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=3 / limit-refs=3 / limit-modes / me=3 / subme=3 / merange=25 / temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=4 / selective-sao=4 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=1.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=20.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=2 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=1 / transfer=1 / colormatrix=1 / chromaloc=0 / display-window=0 / cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / hist-threshold=0.01 / no-opt-cu-delta-qp / no-aq-motion / no-hdr10 / no-hdr10-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=0 / analysis-save-reuse-level=0 / analysis-load-reuse-level=0 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00 / no-scenecut-aware-qpconformance-window-offsets / right=0 / bottom=0
    Default                                  : Yes
    Forced                                   : No
    Color range                              : Limited
    Color primaries                          : BT.709
    Transfer characteristics                 : BT.709
    Matrix coefficients                      : BT.709
    Handbrake x265(standard 8 bit) Using CQ 20 with Slow Preset Encode time 48:30 CPU Load Average 25-30% Max
    Code:
    General
    Unique ID                                : 319035717207895850598327238314628663491 (0xF0040B4ACA91CD43FBD77C92562EC8C3)
    Complete name                            : C:\30 minute test 1080p HB.mkv
    Format                                   : Matroska
    Format version                           : Version 4 / Version 2
    File size                                : 603 MiB
    Duration                                 : 30 min 0 s
    Overall bit rate                         : 2 809 kb/s
    Encoded date                             : UTC 2020-08-14 01:33:33
    Writing application                      : HandBrake 1.3.3 2020061300
    Writing library                          : Lavf58.29.100
    ErrorDetectionType                       : Per level 1
    
    Video
    ID                                       : 1
    Format                                   : HEVC
    Format/Info                              : High Efficiency Video Coding
    Format profile                           : Main@L4@High
    Codec ID                                 : V_MPEGH/ISO/HEVC
    Duration                                 : 30 min 0 s
    Bit rate                                 : 2 753 kb/s
    Width                                    : 1 920 pixels
    Height                                   : 800 pixels
    Display aspect ratio                     : 2.40:1
    Frame rate mode                          : Constant
    Frame rate                               : 23.976 (24000/1001) FPS
    Color space                              : YUV
    Chroma subsampling                       : 4:2:0
    Bit depth                                : 8 bits
    Bits/(Pixel*Frame)                       : 0.075
    Stream size                              : 591 MiB (98%)
    Writing library                          : x265 3.2.1+1-b5c86a64bbbe:[Windows][GCC 9.2.0][64 bit] 8bit+10bit+12bit
    Encoding settings                        : cpuid=1111039 / frame-threads=5 / numa-pools=32 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x800 / interlace=0 / total-frames=0 / level-idc=40 / high-tier=1 / uhd-bd=0 / ref=4 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=24 / keyint=240 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=25 / lookahead-slices=4 / scenecut=40 / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=2 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=3 / limit-refs=3 / limit-modes / me=3 / subme=3 / merange=57 / temporal-mvp / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=4 / selective-sao=4 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=1.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=20.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / vbv-maxrate=30000 / vbv-bufsize=30000 / vbv-init=0.9 / crf-max=0.0 / crf-min=0.0 / ipratio=1.40 / pbratio=1.30 / aq-mode=2 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=1 / transfer=1 / colormatrix=1 / chromaloc=0 / display-window=0 / cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=5 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00
    Default                                  : Yes
    Forced                                   : No
    Color range                              : Limited
    Color primaries                          : BT.709
    Transfer characteristics                 : BT.709
    Matrix coefficients                      : BT.709
    EDIT: I noticed the handbrake encode shows "Format profile as Main@L4@High" Both were set at Main@L4. I dunno why the handbrake encode has @High at the end, instead of @Main.
    Quote Quote  
  19. Try adding these options
    Code:
    ctu=32:merange=25
    to Handbrake's x264 Extra Options box.
    Quote Quote  
  20. Member
    Join Date
    Jun 2007
    Location
    United States
    Search Comp PM
    Originally Posted by jagabo View Post
    Try adding these options
    Code:
    ctu=32:merange=25
    to Handbrake's x264 Extra Options box.
    That has helped, no question. Is there a way to tweak that even more? It's still a bit slower than RB264. CPU usage is for sure higher at around 60%, still about 20% lower than RB264, usage wise.
    Quote Quote  
  21. I saw other differences too but those where the ones I thought would make biggest difference. All I can suggest is you compare the rest of the settings and make them the same too.

    And try turning off/on GPU decoding of the source in Handbrake's settings.
    Quote Quote  
  22. Member
    Join Date
    Jun 2007
    Location
    United States
    Search Comp PM
    I am curious how do these settings get input in different programs? I know with Megui, it uses "--" before each setting inputted. Handbrake it seems just inputting the setting, with a space between the next setting.

    I guess i will need to mess around a bit more with settings, when I have time. I wish there was a way to know exactly what each one does. As them two settings alone double the CPU usage for handbrake, with my 3950x.
    Quote Quote  
  23. Originally Posted by cowboysroy31 View Post
    I am curious how do these settings get input in different programs? I know with Megui, it uses "--" before each setting inputted. Handbrake it seems just inputting the setting, with a space between the next setting.
    Handbrake requires a colon in between the settings. If you used a space -- everything after the space was ignored (without any warning).
    Last edited by jagabo; 14th Aug 2020 at 08:27. Reason: typo
    Quote Quote  
  24. Member ricardouk's Avatar
    Join Date
    Mar 2005
    Location
    Portugal
    Search Comp PM
    edited (double posting)
    Last edited by ricardouk; 14th Aug 2020 at 07:52.
    I love it when a plan comes together!
    Quote Quote  
  25. Member ricardouk's Avatar
    Join Date
    Mar 2005
    Location
    Portugal
    Search Comp PM
    cowboysroy31 that's a fast CPU you got there, it puts mine to shame when looking at the encoding times...just redone the test with other programs (official portable versions) with a 1min 2.7k mp4 file, CQ 20, slow preset, no resizing, no audio, source file size: 280MB
    Ripbot - 35minutes
    Handbrake - 33 minutes.
    StaxRip - 36 minutes
    Virtualdub2 - 32 minutes

    Im using latest portable versions, just changing options as i need to match each other, have you looked in Handbrake at the TOOLS---PREFERENCES---ADVANCED---PRIORITY LEVEL, I have that on "low priority" but it might help on your system if you changed it.


    Ripbot mediainfo report
    Code:
    Format                         : HEVC
    Format profile                 : Main@L5@Main
    Stream size                    : 709 MiB (100%)
    Writing library                : x265 3.2+34-8e6db24c1517:[Windows][GCC 9.2.0][64 bit] 8bit+10bit+12bit
    Encoding settings              : cpuid=1064959 / frame-threads=2 / numa-pools=6 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=2720x1530 / interlace=0 / total-frames=1801 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=4 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=30 / keyint=300 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=25 / lookahead-slices=4 / scenecut=40 / hist-scenecut=0 / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=2 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=3 / limit-refs=3 / limit-modes / me=3 / subme=3 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=4 / selective-sao=4 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=1.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=20.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=2 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=1 / transfer=1 / colormatrix=1 / chromaloc=0 / display-window=0 / cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / hist-threshold=0.01 / no-opt-cu-delta-qp / no-aq-motion / no-hdr10 / no-hdr10-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=0 / analysis-save-reuse-level=0 / analysis-load-reuse-level=0 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00 / no-scenecut-aware-qpconformance-window-offsets / right=0 / bottom=0

    Handbrake mediainfo report
    Code:
    Video
    Format                         : HEVC
    Format profile                 : Main@L5@High
    Stream size                    : 629 MiB (98%)
    Writing library                : x265 3.2.1+1-b5c86a64bbbe:[Windows][GCC 9.2.0][64 bit] 8bit+10bit+12bit
    Encoding settings              : cpuid=1064959 / frame-threads=2 / numa-pools=6 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=2720x1530 / interlace=0 / total-frames=0 / level-idc=50 / high-tier=1 / uhd-bd=0 / ref=4 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=30 / keyint=300 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=25 / lookahead-slices=4 / scenecut=40 / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=2 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=3 / limit-refs=3 / limit-modes / me=3 / subme=3 / merange=57 / temporal-mvp / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=4 / selective-sao=4 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=1.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=20.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / vbv-maxrate=100000 / vbv-bufsize=100000 / vbv-init=0.9 / crf-max=0.0 / crf-min=0.0 / ipratio=1.40 / pbratio=1.30 / aq-mode=2 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=1 / transfer=1 / colormatrix=1 / chromaloc=0 / display-window=0 / cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=5 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00
    Staxrip mediainfo report
    Code:
    Format                         : HEVC
    Format profile                 : Main@L5@Main
    Stream size                    : 706 MiB (100%)
    Writing library                : x265 3.4+6-g73f96ff39:[Windows][GCC 11.0.0][64 bit] 8bit+10bit+12bit
    Encoding settings              : cpuid=1064959 / frame-threads=2 / numa-pools=6 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=2720x1528 / interlace=0 / total-frames=1801 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=4 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=25 / keyint=250 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=25 / lookahead-slices=4 / scenecut=40 / hist-scenecut=0 / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=2 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=3 / limit-refs=3 / limit-modes / me=3 / subme=3 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=4 / selective-sao=4 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=1.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=20.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=2 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=1 / transfer=1 / colormatrix=1 / chromaloc=0 / display-window=0 / cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / hist-threshold=0.01 / no-opt-cu-delta-qp / no-aq-motion / no-hdr10 / no-hdr10-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=0 / analysis-save-reuse-level=0 / analysis-load-reuse-level=0 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00 / no-scenecut-aware-qpconformance-window-offsets / right=0 / bottom=0 / decoder-max-rate=0

    Virtualdub 2 mediainfo report
    Code:
    Format                         : HEVC
    Format profile                 : Main@L5@Main
    Stream size                    : 506 MiB (98%)
    Writing library                : x265 2.5+12-fcd9154fa4e2:[Windows][GCC 7.2.0][64 bit] 8bit+10bit+12bit
    Encoding settings              : cpuid=1105919 / frame-threads=2 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=2720x1530 / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=4 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=25 / keyint=250 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=25 / lookahead-slices=4 / scenecut=40 / no-intra-refresh / ctu=64 / min-cu-size=8 / rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=2 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=3 / limit-refs=3 / limit-modes / me=3 / subme=3 / merange=57 / temporal-mvp / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=4 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=1.00 / no-rd-refine / analysis-reuse-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=20.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=1 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt / no-dhdr10-opt / analysis-reuse-level=5 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=0 / no-limit-sao / ctu-info=0
    Last edited by ricardouk; 14th Aug 2020 at 08:24.
    I love it when a plan comes together!
    Quote Quote  
  26. Member
    Join Date
    Jun 2007
    Location
    United States
    Search Comp PM
    Well I messed around a little before I was to tired last night. I tested these settings on two different programs, one being RB264. Which I just did a test on that same 30 minute file I used last night. I went from 18:00, down to 13:30. Another good sized decrease in encoding time. Overall this is on a 1080p file, which normally doesn't push my CPU at default settings.

    Also looking over the test file I just encoded today, vs the one I did last night with RB264. Last night final file size was 616MB, today's 612MB. Only a 4MB difference. I haven't had time to fully look hard at the quality of each encode. However I doubt I find much difference between the two. As for the three settings I am using currently, which overall.. I have no clue exactly what they do, in terms of quality with x265 encoding. I just know on 1080p, and less resolutions, they're greatly decreasing my encoding time, and pushing my CPU much harder.

    Code:
    --min-cu-size=16 --ctu=32 --merange=25
    Quote Quote  



Similar Threads