HAP choppy playback

[Yousefjuma]

Hello,

 

We have been facing a problem with HAP playback. Sometimes, the playback is not smooth (choppy) randomly under the exact same circumstances (the same PC, video file, position in timeline etc). 

 

Some facts:

• We usually use After Effects to encode videos into HAP.

• Once a video starts, it either works perfectly fine until the end of it or runs choppily until the end of the video. 

• The problem occurred in several different events with different video files.
• The most recent time we faced this problem we were running 2 videos each with resolution of 3338x1920px. With the WO display have 4x 1920x1080 outputs.
• The problem happened with 2 different Display WO with almost the same hardware.

 

Display WO specifications (Tweaked as recommended by Dataton):

• Motherboard: ASRock Fatal1ty X99 Professional
• Graphics card: FirePro W9100
• Processor: Intel Genuine @2.00GHz 18 cores
• Disks: Samsung EVO 850 240GB (Windows) - Samsung EVO Pro 950 M.2 512GB  (WO + Media)
• RAM: 16 GB DDR4 1600Mhz (1 chip)
• OS: Windows 7 Professional - Service Pack 1
• WO version: 6.1.6
• Case: Very good ventilation

Looking forward for your collaboration 

[Thomas Leong]

Have you updated the ASRock BIOS?

 

With my ASRock Z270M, I had to update the BIOS to get smooth playback with Hap codec files, changing nothing else.

[Jim Testa]

You also want to make sure you are encoding with 'chuncks' greater than 1 to make the decoding more efficient.  A setting of 4 is common but in your case 6 or 8 will be worth a try.  

[Claude.Rivet]

Hello,

 

A few things to consider:

-Update win7 to the latest service pack (sp3 I think)

-If given the choice pick faster clock over number of cores, Watchout uses 2 cores mainly, it is a 32bit app also. Capture cards and external control can lead to more than 2 cores being used but at a fraction of the first 2. Since you work with HAP speed, not concurrent processing, is important, the GPU works, not the CPU.

-Update your BIOS, M.2 drives are constantly getting performance boost and stability improvement trough those, they are recent and still being tweaked by BIOS vendors.

-If you have the W9100 you need the S400 sync board or else you do not framelock, which leads to your problem of having only two computer in a cluster performing badly, if you were framelocked they would ALL perform badly (or not) the exact same way on the exact same frame. just having an S400 board and connecting it is not enough, you need to configure it if the AMD graphic card advanced settings. First you define a master and lock each of the card output on that timing master for each computer in your cluster, for the master computer it means choosing input 1 as the sync source for example and then slaving each other output to the output 1 and then setting the RJ45 connections to that master, then in each other computer you set the receiving RJ45 as the master and slave your outputs and the outputing RJ45 (for the daisy chain) to it. You also need to identify in Watchout which output is the sync chain master.

 

That being said I encountered the same issues you are having. If the payback is choppy under the same circumstances every playback it is usually because of your file bandwidth (or some other bottleneck). HAP bandwidth is variable, very variable, so some frame might require 800MB/s while other demand 1.4GB/s. After some testing we came to the conclusion that smal gradients where the issue; fire, smoke, fancy light bubbles, HAP has a hard time encoding those or rather keeping the bandwidth low. Noise, if not blurred, doesn't display this issue, it is always as soon as small gradients are found (a sky is not an issue, it is a gradient but it is big).

The only way to reduce the bandwidth is by reducing the file size (resolution), the only painful way I found to figure out by what exact amount is by encoding the file with FFmpeg and watching the cmd line output as it encodes to spot the highest bandwith peak, if I peak at 1.8GB/s and my storage is giving out 900MB/s max then I know I have to reduce the size by 50% so HAP encodes it within my hardware spec. 

I am currently writing an encoder, an FFmpeg interface actually, that amongst other tracks your HAP bandwith trough the encode process and auto resize the file in a second pass if the first one leads to frames encoded at a superior bandwidth that the system can take. Other than that I don't know of any way to manage it in an automated manner.

 

A note about encoding in chunks, if you plan on playing back concurent files do not encode in chunk as it allows bigger files to be played back, yes, but at the expense of limiting the amount of concurrent files that can be played back. If I encode in chunks I can play 4 HD files before stuttering happens, without chunks I can play 56 HD files before it does. The difference is huge. However I can play back larger files when encoding in chunk than without, it is a tradeoff. As a general rule of thumb you want to encode in a number of chunks equal to half the number of cores on the playback computer so that you have no issue crossfading between files.

 

That's what I see for now, hope it helps.

[Yousefjuma]

Have you updated the ASRock BIOS?

 

With my ASRock Z270M, I had to update the BIOS to get smooth playback with Hap codec files, changing nothing else.

 

We have the second latest BIOS. The latest BIOS provides update regarding EZ OC and NTFS which I believe won't matter. Thanks for your response. 

[Yousefjuma]

You also want to make sure you are encoding with 'chuncks' greater than 1 to make the decoding more efficient.  A setting of 4 is common but in your case 6 or 8 will be worth a try.  

 

We are studying and experimenting that. Will be back with the results. Thanks.

[Thomas Leong]

Yousefjuma, please clarify what you mean by the following -

 

"RAM: 16 GB DDR4 1600Mhz (1 chip)"

 

The '1 chip' qualification is confusing.

 

Do you mean:

1. 1 stick of RAM at 16GB?; or

2. 2 sticks for RAM, each at 8GB, i.e. 2 x 8GB = 16GB?; or

3. 4 sticks of RAM, each at 4GB, i.e. 4 x 4GB = 16GB?

 

This is because the LGA2011-3 processor supports quad-channel RAM, meaning one needs 4 sticks of RAM (preferably matched) for optimum performance.

 

Thomas Leong

[Thomas Leong]

We have the second latest BIOS. The latest BIOS provides update regarding EZ OC and NTFS which I believe won't matter. Thanks for your response. 

 

In my case, I had 3 BIOS updates, which including the original, means I had 4 BIOS versions to choose from. I tried each one at a time, and the last version had Hap running smoothly with nothing else changed. There was no mention of improved video playback with whatever codec, etc. So I would recommend you try the latest though the Notes do not seem relevant.

[Yousefjuma]

Hello,

 

A few things to consider:

-Update win7 to the latest service pack (sp3 I think)

-If given the choice pick faster clock over number of cores, Watchout uses 2 cores mainly, it is a 32bit app also. Capture cards and external control can lead to more than 2 cores being used but at a fraction of the first 2. Since you work with HAP speed, not concurrent processing, is important, the GPU works, not the CPU.

-Update your BIOS, M.2 drives are constantly getting performance boost and stability improvement trough those, they are recent and still being tweaked by BIOS vendors.

-If you have the W9100 you need the S400 sync board or else you do not framelock, which leads to your problem of having only two computer in a cluster performing badly, if you were framelocked they would ALL perform badly (or not) the exact same way on the exact same frame. just having an S400 board and connecting it is not enough, you need to configure it if the AMD graphic card advanced settings. First you define a master and lock each of the card output on that timing master for each computer in your cluster, for the master computer it means choosing input 1 as the sync source for example and then slaving each other output to the output 1 and then setting the RJ45 connections to that master, then in each other computer you set the receiving RJ45 as the master and slave your outputs and the outputing RJ45 (for the daisy chain) to it. You also need to identify in Watchout which output is the sync chain master.

 

That being said I encountered the same issues you are having. If the payback is choppy under the same circumstances every playback it is usually because of your file bandwidth (or some other bottleneck). HAP bandwidth is variable, very variable, so some frame might require 800MB/s while other demand 1.4GB/s. After some testing we came to the conclusion that smal gradients where the issue; fire, smoke, fancy light bubbles, HAP has a hard time encoding those or rather keeping the bandwidth low. Noise, if not blurred, doesn't display this issue, it is always as soon as small gradients are found (a sky is not an issue, it is a gradient but it is big).

The only way to reduce the bandwidth is by reducing the file size (resolution), the only painful way I found to figure out by what exact amount is by encoding the file with FFmpeg and watching the cmd line output as it encodes to spot the highest bandwith peak, if I peak at 1.8GB/s and my storage is giving out 900MB/s max then I know I have to reduce the size by 50% so HAP encodes it within my hardware spec. 

I am currently writing an encoder, an FFmpeg interface actually, that amongst other tracks your HAP bandwith trough the encode process and auto resize the file in a second pass if the first one leads to frames encoded at a superior bandwidth that the system can take. Other than that I don't know of any way to manage it in an automated manner.

 

A note about encoding in chunks, if you plan on playing back concurent files do not encode in chunk as it allows bigger files to be played back, yes, but at the expense of limiting the amount of concurrent files that can be played back. If I encode in chunks I can play 4 HD files before stuttering happens, without chunks I can play 56 HD files before it does. The difference is huge. However I can play back larger files when encoding in chunk than without, it is a tradeoff. As a general rule of thumb you want to encode in a number of chunks equal to half the number of cores on the playback computer so that you have no issue crossfading between files.

 

That's what I see for now, hope it helps.

 

Thanks a lot for your resourceful feedback! It makes a lot of sense to me. We are experimenting still. We will get back to you when we have some outcomes

[Yousefjuma]

Yousefjuma, please clarify what you mean by the following -

 

"RAM: 16 GB DDR4 1600Mhz (1 chip)"

 

The '1 chip' qualification is confusing.

 

Do you mean:

1. 1 stick of RAM at 16GB?; or

2. 2 sticks for RAM, each at 8GB, i.e. 2 x 8GB = 16GB?; or

3. 4 sticks of RAM, each at 4GB, i.e. 4 x 4GB = 16GB?

 

This is because the LGA2011-3 processor supports quad-channel RAM, meaning one needs 4 sticks of RAM (preferably matched) for optimum performance.

 

Thomas Leong

 

I meant 1 stick.

[Yousefjuma]

In my case, I had 3 BIOS updates, which including the original, means I had 4 BIOS versions to choose from. I tried each one at a time, and the last version had Hap running smoothly with nothing else changed. There was no mention of improved video playback with whatever codec, etc. So I would recommend you try the latest though the Notes do not seem relevant.

 

Will try that and get back to you. Your feedback is much appreciated.

[Thomas Leong]

I meant 1 stick.

 

 

I'm not familiar with your "Processor: Intel Genuine @2.00GHz 18 cores".

If it is an LGA2011 or LGA2011-3 platform, then the processor supports 4-channel RAM. This means you need at least 4 sticks of RAM for optimal performance.