Topic: Some results from QTGMC & HEVC encoding tests
I've been tooling around with Hybrid, trying to squeeze maximum performance out of it for QTGMC deinterlacing + Bobbing, followed by x265 encoding.
Hybrid's latest release (2017.02.12.2) is stable on my encoding rig, based on my test runs today. More important than that is the fact that a processing bottleneck that used to slow down QTGMC and multithreaded Avisynth performance has been removed from the pipeline.
This bottleneck on an earlier version of Hybrid was evident when I attempted QTGMC deinterlacing + bobbing for NVEncC encoding on a GTX 1060: the encoding speed hovered around 2 fps. On a new development version of Hybrid the encoding speed suddenly jumped to 13.50 fps, proving the removal of the bottleneck.
Since GTX 1060's HEVC encoder leaves quite a bit of room for improvement visual quality wise, I decided to see what kind of encoding performance I could get when running both QTGMC and x265 software encoder simultaneously. So instead of QTGMC being done on the CPU and encoding on the GPU, now QTGMC processing and encoding are both done on the CPU.
First some data on the rig and Hybrid settings used.
• Dual Xeon X5660 Westmere (MMX, SSE-SSE4.2)
• 12GB of RAM
• Windows 7 64-bit
Some Hybrid settings on Filtering > Avisynth > Misc page:
• "distributor()" enabled
• Memory max 1536 with "double" enabled
• "enforce 8bit" enabled
• 1080i 29.97fps TFF, mpeg2 .ts, video bitrate 16.8 mbps, 6580 frames in length
• 1080p59.94, H.265 .mkv, video bitrate <10 mbps
The first thing I noticed was that an x265 executable compiled on MSVC was slightly faster on my rig than an executable compiled on GCC. Hence the following tests were all done on the MSVC-compiled x265.
What the results seem to show is that raising thread count for Edi and MT does not result in faster encoding. That's at least partly because adding threads takes CPU cycles away from x265 encoder which is otherwise happy to use all available CPU cycles. Raising thread counts certainly shows up on Avisynth benchmark as increased # of threads, higher CPU usage and even higher average fps but those results do not translate to real-world encoding scenarios.
I'll do additional encoding tests using GPU acceleration instead of x265 to see how Edi & MT thread counts affect performance when encoding is not done by the CPU.