Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
![]() |
#6421 | Link |
Registered User
Join Date: Jul 2018
Posts: 162
|
Tested binaries download from here.
input.mkv - hevc (Main 10), yuv420p10le(tv), 3840x1606 AVX2 clock speed = AVX512 clock speed Code:
ffmpeg -i input.mkv -f yuv4mpegpipe -strict -1 - | .\resources\x265-10b.exe --y4m - --ctu 32 -o .\OUTPUT.mkv x265 [info]: HEVC encoder version 2.8+74-fd517ae68f93 x265 [info]: build info [Windows][GCC 8.2.0][64 bit] 10bit x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2 encoded 498 frames in 51.34s (9.70 fps), 5044.61 kb/s, Avg QP:31.42 x265 [info]: HEVC encoder version 2.8+74-fd517ae68f93 x265 [info]: build info [Windows][MSVC 1915][64 bit] 10bit x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2 encoded 498 frames in 51.80s (9.61 fps), 5044.61 kb/s, Avg QP:31.42 Code:
ffmpeg -i input.mkv -f yuv4mpegpipe -strict -1 - | .\resources\x265-10b.exe --y4m - --ctu 32 -o .\OUTPUT.mkv x265 [info]: HEVC encoder version 2.9+2-7e978ed93d60 x265 [info]: build info [Windows][GCC 8.2.0][64 bit] 10bit x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2 encoded 498 frames in 52.82s (9.43 fps), 5044.61 kb/s, Avg QP:31.42 x265 [info]: HEVC encoder version 2.9+2-7e978ed93d60 x265 [info]: build info [Windows][MSVC 1915][64 bit] 10bit x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2 encoded 498 frames in 51.55s (9.66 fps), 5044.61 kb/s, Avg QP:31.42 Code:
ffmpeg -i input.mkv -f yuv4mpegpipe -strict -1 - | .\resources\x265-10b.exe --y4m - --ctu 32 -o .\OUTPUT.mkv VS 2017 Generic compilation ("none") encoded 498 frames in 51.49s (9.67 fps), 5044.61 kb/s, Avg QP:31.42 VS 2017 AVX2 compilation ("AVX2") encoded 498 frames in 52.27s (9.53 fps), 5044.61 kb/s, Avg QP:31.42 Code:
ffmpeg -i input.mkv -f yuv4mpegpipe -strict -1 - | .\resources\x265-10b.exe --y4m - --ctu 32 (--asm avx512) -o .\OUTPUT.mkv x265 [info]: HEVC encoder version 2.9+2-7e978ed93d60 x265 [info]: build info [Windows][MSVC 1915][64 bit] 10bit x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2 encoded 498 frames in 52.05s (9.57 fps), 5044.61 kb/s, Avg QP:31.42 x265 [info]: HEVC encoder version 2.9+2-7e978ed93d60 x265 [info]: build info [Windows][MSVC 1915][64 bit] 10bit x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2 AVX512 encoded 498 frames in 50.79s (9.80 fps), 5044.61 kb/s, Avg QP:31.42 |
![]() |
![]() |
![]() |
#6422 | Link |
Registered User
Join Date: Aug 2014
Posts: 24
|
I tried a short test clip with avx512 enabled and disabled on a 4K source using the slower preset. FPS went up to 1.37 from 0.84 when I enabled 512.
Encoded clip looks good, no obvious errors that is. File size is roughly the same, but clip length and crf might have something to do with the tiny difference between the two. 64bit x265 on an intel 7820x. Temps are roughly equal to when 512 is disabled. Load is mostly at 100% on all cores with the occasional dip down to 87% every minute or so. |
![]() |
![]() |
![]() |
#6424 | Link | |
RipBot264 author
Join Date: May 2006
Location: Poland
Posts: 7,512
|
Quote:
The longer you encode the more heat your cpu will produce and hence more aggressive AVX negative offset will be activated.
__________________
Windows 7 Image Updater - SkyLake\KabyLake\CoffeLake\Ryzen Threadripper |
|
![]() |
![]() |
![]() |
#6425 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,972
|
Has anybody made any recent tests with different CTU and TU sizes? I made a quick test yesterday on a 720p encode, and max CTU (and TU) 16 turned out to produce the smallest file but also looked best compared to the original frame. At CTU max 64, the frame was clearly more blurry in places where there were more small details such as hair etc.
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
![]() |
![]() |
![]() |
#6426 | Link | |
Registered User
Join Date: Nov 2009
Posts: 59
|
Quote:
|
|
![]() |
![]() |
![]() |
#6427 | Link |
Registered User
Join Date: Apr 2016
Posts: 61
|
Pushing Encoding Quality and Speed with x265
Massively Parallel Encoding from Mile-High Video Workshop videos http://mile-high.video/files/mhv2018/ |
![]() |
![]() |
![]() |
#6428 | Link | |
Moderator
![]() Join Date: Jan 2006
Location: Portland, OR
Posts: 3,460
|
Quote:
rc: Fix rowStat computation in const-vbv It looks like it might fix a serious issue in a given RC mode, but it isn't actually self-documenting. |
|
![]() |
![]() |
![]() |
#6430 | Link | |
Pig on the wing
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,972
|
Quote:
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
|
![]() |
![]() |
![]() |
#6431 | Link | |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,322
|
Quote:
Still, there seems to be a lack of communication recently. I reported compiler warnings of GCC 8.x already 2 times, and nobody replied until today. Last edited by LigH; 16th October 2018 at 07:59. |
|
![]() |
![]() |
![]() |
#6432 | Link | |
I am maddo saientisto!
Join Date: Aug 2018
Posts: 103
|
Quote:
But that's probably just me wishfully hoping for a sane AV1 encoder with proper performance, multithreading, profiles and documentation... |
|
![]() |
![]() |
![]() |
#6433 | Link | |
Moderator
![]() Join Date: Jan 2006
Location: Portland, OR
Posts: 3,460
|
Quote:
Larger CTUs are definitely helpful at lower bitrates. Comparing at high perceptual quality can bring in other subtler differences between modes. I've even been able to see a slight improvement at sub-SD resolutions using CTU 64 at very low bitrates. |
|
![]() |
![]() |
![]() |
#6434 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,972
|
Source was 4K, downsampled to 1080p. These are the basic parameters that I've set:
Code:
--input-depth 16 --dither --profile main10 --min-keyint 5 --keyint 480 --merange 44 --splitrd-skip --preset veryslow --rc-lookahead 60 --deblock -2:-2 --no-strong-intra-smoothing --no-sao --qcomp 0.8 --aq-mode 3 --aq-strength 0.8 --ctu 64 --max-tu-size 32 --rdpenalty 1 --qg-size 16 --tu-inter-depth 4 --tu-intra-depth 4 --limit-tu 4 --limit-refs 3 --max-merge 2 --rd-refine --ref 6 --bframes 10 --crf 19 In the 1080p encode, the bitrate is as follows: CTU 64 / TU 32 - 15078 kbps CTU 32 / TU 32 - 14608 kbps CTU 32 / TU 16 - 14472 kbps Of these, CTU 32 / TU 32 resembles the original the most. It's interesting that setting TU 16 also causes distortion in the same areas as CTU 64 / TU 32. I checked areas like eyes, hair etc. which have easily some sort of distortion because there are many fine lines and things that can be compared quite easily. I've just started testing what CRF value is visually enough for 1080p so the final bitrate will probably be lower than what I got from my tests. I'd estimate CRF 20-21 would be the final value.
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
![]() |
![]() |
![]() |
#6435 | Link | |
Moderator
![]() Join Date: Jan 2006
Location: Portland, OR
Posts: 3,460
|
Quote:
Overall, that is a very idiosyncratic set of options. Nothing looks wrong (and I'd love to hear who you picked some of those!, but it's definitely outside of any combination of settings that MCW would be doing psychovisual optimization for. I'm curious about why you chose these particular settings:
|
|
![]() |
![]() |
![]() |
#6436 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,972
|
My sources are just regular movies or TV series. I'll tune CRF as the last item once I've got all the rest in place.
--merange 44, basically lowering it from the default 57 which I understand is meant for 4K. For 720p, I've used 38 all the time. I think this is remains of littlepox's set of "tune film" parameters. --splitrd-skip, in my old notes, I didn't find it cause any ill effects. Do you have any specific information why it's a "bad idea"? --max-merge 2, values 3-4 tested and it caused blur. One of the things in x265 that is different from x264 - the slower presets don't mean similar quality at lower final bitrate --deblock -2:-2, no need for intense deblocking according to my tests --rdpenalty 1, trying to favour smaller blocks. --qg-size 16, tested values from 64 to 8, 16 looked best (in terms of distortion in small details again) when compared frame-by-frame. Tested with a 720p encode, so I'll need to check that also with 1080p later. --bframes 10, some video utilizes a lot of B-frames for some reason. Not a big slowdown so I've kept it at that all the time.
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
![]() |
![]() |
![]() |
#6437 | Link | |||||||
Moderator
![]() Join Date: Jan 2006
Location: Portland, OR
Posts: 3,460
|
Quote:
Quote:
Anyone from MultiCoreWare care to weigh in? What's the tradeoff? Is this something that should get added to the faster presets, or default to On but off in --preset placebo? Quote:
Quote:
Quote:
Quote:
Quote:
|
|||||||
![]() |
![]() |
![]() |
#6438 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Hollola, Finland
Posts: 4,972
|
I think the general problem is that the presets and tunings are really old. I'm quite sure things are very much different now compared to what they were when most of the parameters and settings were come up with. Also, we are still missing the most common tuning which is --tune film. I would very much like to see what the creators of the encoder think of proper settings as they should know the internal workings best.
I recall someone else also complaining about max-merge for smoothing things if the value is too big. I'll need to retest and file a bug report if it's still reproducable. It's been some time since I tested it. Will also retest deblock 0:0. When I tested it earlier, I did find it smooth things slightly so I went one notch down from the standard -1:-1 of x264's --tune film. --rdpenalty 1 is something I have not tested recently. --qg-size 16 does cause the bitrate to jump compared to 32 or 64, but it's worth it in my opinion. I had tested it with a 720p encode with quite a big filesize difference: qg-size 64 : 3147,41 kbps qg-size 32 : 3648,01 kbps qg-size 16 : 3954,23 kbps It is something I need to separately retest for 1080p. The bitrates fluctuate a lot, I'd say between 2.5 - 6 Mbps for 720p encodes. I have no specific target so I just use CRF 19. 10 B-frames because for some quite noisy sources, I noticed that 8 consecutive B-frames were being used 5-10% of the time. Setting ten usually meant that the longest sequence was used 1-2% of the time.
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... Last edited by Boulder; 16th October 2018 at 18:11. |
![]() |
![]() |
![]() |
#6440 | Link |
Moderator
![]() Join Date: Jan 2006
Location: Portland, OR
Posts: 3,460
|
Would it be hotter? Or would it just be slower due to thermal throttling.
I wouldn't be surprised if Intel's next big microarchitecture revision makes AVX512 useful in cases where it isn't today. We saw the same thing with Skylake and AVX2. |
![]() |
![]() |
![]() |
Thread Tools | Search this Thread |
Display Modes | |
|
|