VideoHelp Forum

Our website is made possible by displaying online advertisements to our visitors. Consider supporting us by disable your adblocker or Try ConvertXtoDVD and convert all your movies to DVD. Free trial ! :)
+ Reply to Thread
Results 1 to 22 of 22
Thread
  1. Member
    Join Date
    Dec 2003
    Location
    Norway
    Search Comp PM
    So, I recently upgraded my CPU from R5 2600 to 3600X. I know it's not a massive upgrade but it has decent gains.
    So I expected my encoding times to improve but they really didn't. I'm sitting at around 9-11 fps for the 2nd pass.

    So this is what I do. I edit in Vegas Pro, then I frameserve it to Avisynth+. The only thing I do here is convert back to PC.709 and adjust the colors a bit:
    avisource("d:\source.avi").convertToYV12(matrix="P C.709").Tweak(hue=0.0, sat=1.05, bright=1, cont=1.0, coring=false)

    Then I open the script in MeGUI and convert to x264 with these settings:
    --preset veryslow --pass 2 --bitrate 40000 --stats ".stats" --threads 12 --deblock -1:-1 --keyint 300 --bframes 2 --scenecut 60 --ref 6 --rc-lookahead 40 --merange 16 --partitions p8x8,b8x8,i8x8i4x4 --no-dct-decimate --no-fast-pskip --colormatrix bt709

    I'm seeing ok CPU usage but with this type of workload I would expect it running at 100% load and it does not.

    Any ideas on how I can find bottleneck and if there's anything I can do about it?
    Quote Quote  
  2. What does "I would expect it running at 100% load and it does not" mean? 99 percent? 15 percent?

    Try adding prefetch(6) to the end of your AviSynth script. Any improvement?
    Quote Quote  
  3. Dinosaur Supervisor KarMa's Avatar
    Join Date
    Jul 2015
    Location
    US
    Search Comp PM
    If you are not get 100% usage with very slow then it's probably something to do with your avisynth chain, or something as simple as a decoding bottleneck.

    I'm seeing ok CPU usage but with this type of workload I would expect it running at 100% load and it does not.
    That doesn't tell me much other than it's not 100% usage.
    Quote Quote  
  4. Member
    Join Date
    Dec 2003
    Location
    Norway
    Search Comp PM
    Yeah sorry that was really unspecific.
    Here's a screenshot of usage after 90 secs into 2nd pass:
    Image
    [Attachment 49796 - Click to enlarge]


    Originally Posted by jagabo View Post
    What does "I would expect it running at 100% load and it does not" mean? 99 percent? 15 percent?

    Try adding prefetch(6) to the end of your AviSynth script. Any improvement?
    My first thought was Avisynth. Using this command doubled the speed on 1st pass. Every thread hitting 99-100%.
    But 2nd pass still pretty low. Usage is basically the same as without Prefetch:
    Image
    [Attachment 49797 - Click to enlarge]


    FPS without Prefetch:
    1s tpass, 29.28
    2nd pass, 10.49

    With Prefetch:
    1st pass, 50,53
    2nd pass, 10.50
    Quote Quote  
  5. With the first pass running at 50 fps AviSynth and Vegas aren't the bottleneck*. The 3900X is a 6 core, 12 thread CPU. Try increasing the number of x264 threads to 18 (1.5x the number of CPU threads is the default for x264 for a reason).

    * There's one possible exception I can see though: If your source is a long GOP codec out-of-order requests from x264 could cause Vegas to seek back and forth through the video, slowing it down.
    Quote Quote  
  6. Member
    Join Date
    Dec 2003
    Location
    Norway
    Search Comp PM
    Originally Posted by jagabo View Post
    With the first pass running at 50 fps AviSynth and Vegas aren't the bottleneck*. The 3900X is a 6 core, 12 thread CPU. Try increasing the number of x264 threads to 18 (1.5x the number of CPU threads is the default for x264 for a reason).
    It wouldn't let me go higher than 16. This did bump the fps to 11.89 and at least parts of the video saw near max usage on all threads while it still dipped quite low at times.

    Originally Posted by jagabo View Post
    * There's one possible exception I can see though: If your source is a long GOP codec out-of-order requests from x264 could cause Vegas to seek back and forth through the video, slowing it down.
    My source is video game footage recorded with the NVENC codec:
    Code:
    ID : 1 
    Format : AVC 
    Format/Info : Advanced Video Codec 
    Format profile : High@L5.1 
    Format settings : CABAC / 1 Ref Frames 
    Format settings, CABAC : Yes 
    Format settings, RefFrames : 1 frame 
    Format settings, GOP : M=1, N=30 
    Codec ID : avc1 
    Codec ID/Info : Advanced Video Coding 
    Duration : 17 min 25 s 
    Source duration : 17 min 25 s 
    Bit rate : 48.9 Mb/s 
    Width : 2 560 pixels 
    Height : 1 440 pixels 
    Display aspect ratio : 16:9 
    Frame rate mode : Variable 
    Frame rate : 60.000 FPS 
    Minimum frame rate : 50.392 FPS 
    Maximum frame rate : 70.588 FPS 
    Standard : PAL 
    Color space : YUV 
    Chroma subsampling : 4:2:0 
    Bit depth : 8 bits 
    Scan type : Progressive 
    Bits/(Pixel*Frame) : 0.221 
    Stream size : 5.95 GiB (100%) 
    Source stream size : 5.95 GiB (100%) 
    Title : VideoHandle 
    Encoded date : UTC 2019-08-11 16:04:14 
    Tagged date : UTC 2019-08-11 16:04:14 
    Color range : Limited 
    Color primaries : BT.601 NTSC 
    Transfer characteristics : BT.470 System M 
    Matrix coefficients : BT.601 
    mdhd_Duration : 1045500 
    Codec configuration box : avcC
    Quote Quote  
  7. Run multiple instances of x264 like I do
    Quote Quote  
  8. Going up to 18 (or more) will probably get you a few percent better performance (and higher CPU usage). But it's hardly worth worrying about. FYI, on my quad core system going from 4 to 5 threads gets about 25 percent more performance. Going from 5 to 6 threads gets only an additional 5 percent.

    I don't know why MeGUI limits you to 16 threads. I've used the x264 command line encoder with 64 threads (in testing, I only have a quad core CPU) without problems.
    Last edited by jagabo; 14th Aug 2019 at 18:06.
    Quote Quote  
  9. Member
    Join Date
    Dec 2003
    Location
    Norway
    Search Comp PM
    Perhaps I should try the command line encoder. Can I make it use the .xml profile that I have saved with MeGUI?
    Quote Quote  
  10. The options you gave in the first post are all native x264 CLI format. You just need to add source and output options.

    x264 --preset veryslow --pass 2 --bitrate 40000 --stats ".stats" --threads 12 --deblock -1:-1 --keyint 300 --bframes 2 --scenecut 60 --ref 6 --rc-lookahead 40 --merange 16 --partitions p8x8,b8x8,i8x8i4x4 --no-dct-decimate --no-fast-pskip --colormatrix bt709 --output "OUTPUT.MKV" INPUT.AVS
    Quote Quote  
  11. Member
    Join Date
    Dec 2003
    Location
    Norway
    Search Comp PM
    Yes of course

    Got this error though, using the latest .exe
    x264 [error]: not compiled with MP4 output support

    So I tried changing it to .mkv and got this error:
    avs [error]: AVISource: couldn't locate a decompressor for fourcc DFSC
    (D:\Avisynth scripts\source.avs, line 5)
    x264 [error]: could not open input file `D:\Avisynth scripts\source.avs'
    Quote Quote  
  12. For the MP4 problem you just need to find a build with mp4 support. The problem is an AviSynth error, not an x264 error. AviSynth can't find a VFW decoder for the fourcc "DFSC". It's not likely that same command line would work with MeGUI. You must have changed something else in Vegas. Or maybe you used DirecShowSource() instead of AVISource() before. DirectShowSource() uses DirectShow codecs, AviSource uses VFW codecs.
    Quote Quote  
  13. Member
    Join Date
    Dec 2003
    Location
    Norway
    Search Comp PM
    I've always used AviSource.

    Changing to DirectShowSource gave this error:
    avs [error]: DirectShowSource: Could not open as video or audio.

    Video returned: "DirectShowSource: couldn't open file d:\video.avi:
    Cannot play back the video stream: no suitable decompressor could be found."

    Audio returned: "DirectShowSource: couldn't open file d:\video.avi:
    Cannot play back the video stream: no suitable decompressor could be found."

    (D:\Avisynth scripts\source.avs, line 5)
    x264 [error]: could not open input file `D:\Avisynth scripts\source.avs'
    Quote Quote  
  14. If AviSource() in your AVS script worked with MeGUI it should work with x264 too. Make sure your x264 is the same bitness as MeGUI. If MeGUI is 64 bit x264 should be 64 bit too.
    Quote Quote  
  15. Member
    Join Date
    Dec 2003
    Location
    Norway
    Search Comp PM
    Yep both 64bit. I guess MeGUI has something built-in?

    This is the info from the frameserver:
    Code:
    Video
    ID                                       : 0
    Format                                   : VFW
    Codec ID                                 : DFSC
    Codec ID/Info                            : DebugMode FrameServer VFW
    Duration                                 : 59 s 900 ms
    Bit rate                                 : 3 840 b/s
    Width                                    : 2 560 pixels
    Height                                   : 1 440 pixels
    Display aspect ratio                     : 16:9
    Frame rate                               : 60.000 FPS
    Bits/(Pixel*Frame)                       : 0.000
    Stream size                              : 28.1 KiB (9%)
    Ok, I so I went and checked Debugmode Frameserver website and they have a new release after god knows how many years.
    So now I'm getting a little bit further:
    avs [info]: 2560x1440p 0:0 @ 60/1 fps (cfr)
    x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
    x264 [error]: ratecontrol_init: can't open stats file
    x264 [error]: x264_encoder_open failed

    I guess I have to run a 1st pass first? What bitrate should I use for 1st pass?

    Ok I figured out you just leave it at 40k.
    So here are the results:

    16 threads:
    1st pass - encoded 3607 frames, 70.44 fps, 40828.21 kb/s
    2nd pass - encoded 3607 frames, 12.62 fps, 40137.13 kb/s

    18 threads:
    1st pass - encoded 3607 frames, 69.79 fps, 40821.97 kb/s
    2nd pass - encoded 3607 frames, 12.87 fps, 40136.69 kb/s

    24 threads:
    1st pass - encoded 3607 frames, 69.32 fps, 40827.80 kb/s
    2nd pass - encoded 3607 frames, 13.30 fps, 40117.43 kb/s

    Will test even more threads later. But so far it seems to be working
    Last edited by Amaze; 15th Aug 2019 at 11:06.
    Quote Quote  
  16. Member
    Join Date
    Dec 2003
    Location
    Norway
    Search Comp PM
    Ok had to do a few more.

    32 threads:
    2nd pass - encoded 3607 frames, 13.96 fps, 40101.22 kb/s

    36 threads:
    2nd pass - encoded 3607 frames, 14.01 fps, 40103.25 kb/s

    Looks like diminishing returns are really kicking in here. So I'm looking at a 33% increase in 2nd pass from MeGUI which is really good.

    I did see something about increasing thread count could result in worse quality, but the filesize is exactly the same.
    Quote Quote  
  17. Using too many threads will reduce quality (a bit) and will eventually slow the encoding.
    Quote Quote  
  18. Member
    Join Date
    Dec 2003
    Location
    Norway
    Search Comp PM
    I will have to look over the videos to see if I notice anything. Do you know what I'm specifically looking for quality wise?

    I'm also guessing memory speed don't really affect encoding? It's not like I'm moving 4k video here so no real point in overclocking?

    I'm also wondering if it's possible to make the x264 cli spit out time elapsed when it's finished?
    Last edited by Amaze; 15th Aug 2019 at 14:39.
    Quote Quote  
  19. that latest DMFS introduced 64bit handling, so you can load it now to 64bit aplications

    before it was managed behind the scenes by MeGui with some pipe or something from that 32bit to 64bit, so when you put it directly to 64bit x264 it could not work


    you can make a batch script to see times:
    @echo off
    echo starting time:
    echo %date% %time%
    x264 --preset veryslow etc. ....... x264 cmd line .......
    echo encoding finished:
    echo %date% %time%
    pause
    Quote Quote  
  20. Member
    Join Date
    Dec 2003
    Location
    Norway
    Search Comp PM
    Excellent thanks.

    I also remembered now that AVsP let's you interleave video. So I opened my 16 thread video and compared to a 48 thread video and the 48 video clearly looks worse at 400% zoom.
    But when it comes to 24, 32 and 36 thread I'm having a tough time telling which is worse. I can tell that they are not 100% same, but literally in one frame the 16 bit looks better and in another frame the 36, 24 etc. looks better. The variance is so tiny that I feel I can say 36 and below won't have noticeable quality impact.

    I'll have another look tomorrow when I'm not this sleepy.
    Quote Quote  
  21. Member
    Join Date
    Dec 2003
    Location
    Norway
    Search Comp PM
    Ok, after a bit of testing I've settled back down to 12 threads. I don't particularly like how more threads seem to add "smudge" to edges.
    Will it be noticeable in fullscreen, maybe not, but the more clean a picture is the better.

    I've made a few changes to my settings, but I honestly know very little about them. Is there anything here you would change for video game footage?

    x264 --preset veryslow --pass 1 --bitrate 40000 --stats ".stats" --threads 12 --deblock -2:-1 --keyint 300 --bframes 2 --ref 4 --qcomp 0.9 --merange 20 --partitions p8x8,b8x8,i8x8i4x4 --psy-rd 1.0:1.00 --no-dct-decimate --no-fast-pskip --colormatrix bt709 --output NUL --fps 60 --input-res 2560x1440 "D:\Avisynth scripts\test.avs"


    Went back to old settings, this actually looked worse.
    Last edited by Amaze; 16th Aug 2019 at 17:31.
    Quote Quote  
  22. Originally Posted by Amaze View Post
    Went back to old settings, this actually looked worse.
    Yes, it's annoying when that happens, isn't it?
    Quote Quote  



Similar Threads