hardware acceleration blues

[techpro2004]

I am having trouble with the new gpu decoding feature. I added hardware_decode=1 to my comskip.ini file but no luck. I had gpu-z running as I processed some wtv files using mcebuddy but there was no change on load or core clock. Processing speeds are within 25 fps of each other using different recordings on the same channel, with hardware_decode=0 and hardware_decode=1. My gpu is a gtx 970 running the latest drivers. I am using comskip version 0.81.083. dxva checker says dxva is working on my gpu any assistance is appreciated thanks.

[erik]

Can you mail me the comskip log file with
verbose=10
certain h264 profiles can not be decode with hw assist

[erik]

Could you test build 0.81.084 and report if it makes a difference?

[techpro2004]

version 0.81.084 makes no difference although it is about 200 fps faster. I can not find how to attach my log file to this forum, what is your email address. Please note mcebuddy automatically processes all of my recordings so the log is from a re-process thanks

edit:

I just re ran it and I am noticing a slight difference the core clock goes up for the first 1-2 seconds then it does the same 1 or 2 times during the processing. It does not consistently process in the gpu. thanks

[erik]

Could you drag and drop a recording in comskip.exe with in your comskip.ini file the setting
hardware_decode=1

could you first delete the .logo.txt file if it already exists
and run comskip twice
once without the .logo.txt file, once with the .logo.txt present

If the cpu peaks during logo searching that makes sense as this logo searching is very CPU intensive
if the cpu load is low with .logo.txt present the decoding is done in the GPU.

On my test computer my GPU is so underpowered that HW based decoding is substantially slower then CPU so I can not realy test myself

mail to erik at comskip.org

[techpro2004]

Cpu usage was in the 30's so I am assuming it is not using the gpu. I am sending over the .log file thanks

[techpro2004]

just sent it thanks

[erik]

Processing speed was 2252.36 fps
The video processing by comskip is alway's CPU based, only the decoding can move to the GPU

With 2250 fps the CPU will remain the limiting factor.

GPU decoding is expected to have its biggest impact when you are running at sub 500 fps because then there is load to shift to the GPU

[techpro2004]

So basically what you are saying is my processing speeds are too fast for gpu acceleration? thanks

[erik]

Yes, with speeds above 2000 fps the decoding is for sure not the bottleneck anymore and the video analysis can not be split over mutiple cores or moved to GPU so for the moment you hit the performance limit

[techpro2004]

if the video analysis can not be split over multiple cores then what does the thread_count option do? thanks

[erik]

Thread count is for the video decoder
When you decode mpeg2 in lowres=2 the decoding load is so low it has almost no impact
However when you decode 1080p h264 90% of the work is decoding the video so thread count will have most impact

[techpro2004]

Thanks for explaining that to me. Also it is good to know that I am getting everything that I can out of comskip performance wise. Thank you.

[erik]

Of course your question if the comskip processing itself (not the decoding) is multi-threaded has started some creative ideas but the will take some time

[techpro2004]

sounds nice. I look forward to multi core processing some time in the future. thanks

edit:

Please let me know when you have a pre release version ready so I can test it for you. I use comskip on average on 4 different recordings a day and my system is more than powerful enough to handle it. thanks