QuickSync on Xeon (Windows)

[David_Wilkins]

Hi, we have Wowza on a Xeon E5-2670, and have been trying the transcoder using QuickSync. I’m encountering a few issues:

1. Periodically the framerate drops for a few seconds, and then recovers. Sometimes this is accompanied by CPU spikes from the Java engine. The default encoder does not have the same issue.

2. CPU usage appears to be higher than if I use the default MainConcept encoder, which doesn’t seem right.

Thoughts? And finally:

3. Will the logs reveal if QuickSync can’t be used and it switches to default? I saw the link related to issues with Wowza as a service not being able to access. How would we know if this is affecting us?

[system]

Your log files will show if Quick Sync is available after you start a live stream. For example.

JNI:VideoEncoderH265QuickSyncHost.isAvailable[global]: {Process: processId:9868 sessionId:0 sessionStatus:1} {QSAPIVersion:1.17}

If it is not available you will see the following.

JNI:TranscoderSession.isQuickSyncAvailable[...]: Intel Quick Sync hardware acceleration is NOT available

If Quick Sync is not available then Transcoder will fall back to use the CPU.

Make sure that you have your Transcoder template both decode and encode your content using Quick Sync.

Seeing SKIP1FRAME, SKIP2FRAME, SKIP4FRAME, KEYFRAMESONLY, or ALLFRAMESOFF signals that transcoder is overloaded and is skipping frames in an attempt to keep up with your live feed. This will affect playback of segmented content which may cause your clients to buffer or even disconnect from the live stream. This can fill the java heap rapidly which if that happens will cause Wowza Streaming Engine to restart.

If that is the case then you will need to get better hardware.

[David_Wilkins]

Thanks for the info. So if the log says it found QuickSync, I am not subject to the WIndows service restriction, I assume.

I did find some SKIP1FRAME entries, and I have also found ALLFRAMESON (yes, ON, not OFF) entries. The latter one sounds like it’s restoring normal flow?

The entries only appear when I use QuickSync, and not when I use default.

This is installed on dual Xeon system with 16 cores and 32 GB RAM, running Windows Server 2016. I am transrating six bitrates from 720p to 180p. On default, it uses about 30-35% CPU. On QuickSync CPU goes to 35% or higher, with fluctuations and spikes.

The streams never go down, but I do experience the frame rate reductions on QuickSync.

I did just notice decoder is using default, not QuickSync. I’ll make that change and see what difference it makes.

[David_Wilkins]

Wow, changing decoder to QuickSync causes a lot of problems. CPU is very low, but also many errors and the transrated streams never get off the ground.

In addition to the errors you mentioned, I’m seeing this in the error log:

WARN server comment 2019-06-28 17:30:32 - - - - - 7225.781 - - - - - - - - TranscoderWorkerVideoDecoder.handlePacketVideo[defaultVHost:live/sanjose/enc1_qs: decodeIterations:183]: Video decoder pending frame count[176] is greater than limit[150], resetting

[David_Wilkins]

I have uncovered some new info.

Intel Xeon processors with QuickSync:

https://ark.intel.com/content/www/us/en/ark/search/featurefilter.html?productType=873&1_Filter-Family=595&0_QuickSyncVideo=True

It turns out the E5 processors like I have do not have QuickSync. It’s primarily the E3 processors that have the integrated GPU.

So now the question is… Why is Wowza thinking QuickSync is available? I have found that it is reporting QuickSync as available on my Xeon E5-2670 (right generation, but missing integrated GPU), and even on our older Xeon E5530 (too old for QuickSync).