Their developer docs' enumeration of profiles suggest h.264 High 10 isn't supported by the silicon, though (could be outdated, but *shrug* would be interesting to see the output from something like DXVA Checker on a KL system).Īs for having to hook up an HDMI cable to allow it to function in the presence of a dGPU, I seem to recall a way to bypass that requirement by creating a dummy "monitor" for it, but that may not work with some motherboards (it doesn't on mine, so I keep it connected to a spare port on a nearby television). Intel seems to love touting their HEVC Main10 and VP9 capabilities in KL, but seem to be light on details about any improvements on the h.264 side of things. Kaby Lake might just support it, but I can't find any documentation to support this notion, hence my rather repetitive replies about not knowing if h.264 High 10 is supported in hardware. They are implemented differently in silicon, so 10bit en/decoding doesn't necessarily apply to every codec even on Kaby Lake. If I enable intel quicksync then emby cannot transcode them. The only issue here would be B-frames, but for fast encoding video you could give up 5-15MB video on a 700MB file due to no B-frame support, if it could save you time by processing threads in parallel.I have a few videos in 10 bit h.264 (profile high 10, pixel format yuv420p10le. The data between keyframes can easily be encoded in a parallel pipeline or thread of a cpu or gpu.Įven on mobile platforms integrated graphics have more than 4 shader units, so I suspect even on mobile graphics cards you could run as much as 8 or more threads on encoding (depending on the gpu, between 400 and 800 Mhz), that would be equal to encoding a single thread video at the speed of a cpu encoding with speed of 1,6-6,4GHz, not to mention the laptop or mobile device still has at least one extra thread on the CPU to run the program, and operating system, as well as arrange the threads and be responsible for the reading and writing of data, while the other thread(s) of a CPU could help out the gpu in encoding video.
#Intel quicksync decoder movie#
keyframes are tiny jpegs inserted in a movie preferably when a scenery change happens that is greater than what a motion codec would be able to morph the existing screen into. I would say not long from here we'll see encoders doing video parallel encoding by loading pieces between keyframes. Is this simply the result of using high bitrate Blu-ray source files? But the differences between AMD and Nvidia are less apparent given such mixed results. Overall, Quick Sync soundly trounces CUDA and APP for encoding and decoding performance. The new Core i5-2500K is simply too fast. The suggestion here is that you'd see better results if you were stuck on an older machine with a slower processor and modern graphics card. Unfortunately, using APP in MediaConverter is still slower than using the CPU-only option.
#Intel quicksync decoder software#
Using this smaller clip, AMD's APP is finally faster than the pure software route, but not by much.
#Intel quicksync decoder full#
We are talking about more than a full minute improvement over the times seen in MediaEspresso. If we just go by the numbers, it appears that MediaConverter is better optimized for multithreaded performance as well. Overall, we see much faster transcode times with MediaConverter, though. To encode HEVC/H.265 by QSV hw-encoder you need instruct ffmpeg to use hw-accelerator qsv by -hwaccel qsv, apply HEVC hw-encoder by c:v hevcqsv, in addition you need load hevc plugin (see the example command line). It doesn't offer the granular control enabled by CyberLink. Note that ArcSoft's MediaConverter either uses hardware- or software-based transcoding. Intel's Quick Sync-enabled Core i5-2500K only sees a substantial gain using the quality setting and encode acceleration. Even though our 665 MB H.264/AC3 BDAV clip is the same bitrate as our 31.2 GB movie, we see hardware-accelerated encoding yielding much better results on the Radeon HD 6970 and GeForce GTX 580.
0 kommentar(er)
