This project has moved and is read-only. For the latest updates, please go here.

Public comskip 081.081 has hardware decoding!

Aug 14, 2015 at 12:46 AM
Since you have a setting for hardware decoding that you use with mencoder/ffmpeg I thought it might be relevant that one of the newer comskip's (there's a couple more since then) added an optional ini parameter hardware_decode=0 (0=off/1=on). Enables hardware accelerated video decoding. Only faster when you have a fast graphics card and a slow CPU. Figuring you could adjust the parm with the switch so both are either doing it or not if you thought that was advisable.

I don't see the parm being used in the default comskip.ini so just pointing it out.
Aug 14, 2015 at 4:50 AM
yep that's for max compatibility, most users don't have hardware accelerated systems, but feel free to try it and let us know your feedback. We can add your feedback to the list of things to do to increase performance

Aug 14, 2015 at 5:19 AM
In my case my cpu is much faster. I just thought the config could default to setting it to 0 which disables but if the user enables it in the settings then enable it in comskip in addition to mencoder. Hardware accelerated decoding which is what this is talking about is COMMON for most users but typically their cpu is faster than the video gpu so not sure why you are saying most don't' have it?
Aug 14, 2015 at 2:07 PM
I see what you're saying. If hardware is enabled then enable this option also.

mCEbuddy checks for a hardware accelerator before enabling it. So the check could be extended to this as well. We need to explore this option a little more to see how much improvement it provides.

Aug 15, 2015 at 2:57 PM
I misread your post, no MCEBuddy won't touch the INI file, that's the sanctity of the user settings, because you can even specify custom INI settings it won't be appropriate for MCEBuddy to overwrite the user INI file.

However we're working with Erik to make a special release which allows mcebuddy to control the hardware decoding via the CLI which then MCEbuddy can use.

BTW we've also done some testing on this and found that the hardware decoding only work with quicksync and h.264, with mpeg2 it actually slows it down significantly. Here are some results:

MPEG2 -> 0:33 to 2:53 with hardware
h.264 -> 2:18 to 0:11 with hardware

Again this option only works with 0.81.082 or later build of comskip and ONLY with the donator version.

Aug 15, 2015 at 3:58 PM
Edited Aug 15, 2015 at 4:01 PM
Well starting with 081.082 they added a command line parameter --hwassist that will enable hardware decoding, it will override the setting in comskip.ini without any modification to the ini which is what your doing with mencoder is it not? Just thought I'd point it out since it just came out yesterday and that might be easier for you.

Also does any of this work for H.265? Will quicksync ever be able to? I ask because the file size savings were significant for me but obviously took longer that the 15 minutes or so a quicksync convert did.
Aug 15, 2015 at 11:51 PM
Yes we asked Eric to add that in 082 so we can use it.

However are seeing inconsistent results. Can you please try some videos and report back what you're seeing with your videos (let us know if it's h264, mpeg4 or mpeg2). Even with h.264 we are seeing very inconsistent results, after running a mix of videos it starts getting flaky, sometimes it accelerates and other times it slows it down for the same video.
Aug 19, 2015 at 5:42 AM
BTW we have the code stub in place to automatically enable hardware decoding for H.264 files using build 082 and later of comskip but we aren't enabling it yet.
Reason being is that with build 083 we are seeing it actually slow down with hardware decoding enabled. Are you seeing something similar?
Aug 21, 2015 at 8:11 AM
Right it came out on request from us to Erik :)
We're still doing more testing before it will be ready for release

Aug 21, 2015 at 8:36 PM
When you indicated it took much longer for mpeg2 I opted not to use it because all my tuners are original hdhomerun hdhr-us models and it's my understanding the content is streamed in mpeg2 and stored that way in wtv files. Truthfully I thought it would help older machines as I don't believe my conversions use hardware encoding at all (wtv to h.265 (hvec)) or am I mistaken? It takes the i7 machine I've made my primary pc about 50-60 minutes to do a 1 hour wtv to h.265 mkv conversion. It took 25% of the time to do a h.264 conversion but the file size was double what the h.265 ends up being.
Aug 21, 2015 at 8:42 PM
this is hardware decoding, nothing to do with encoding. The results are extremely flaky in our testing, we've seen increase in mpeg2 decoding and then decrease.

Download the 083 comskip and change the ini file to enable/disable it and try it out and let us know the results. You can find the time taken for comskip to complete at the end of the log file (infact you can hit stop after commercial detection finishes, change the settings and start again, you don't need to wait for the conversion to finish), open the log file and scroll to the bottom performance metrics section.

Aug 26, 2015 at 7:09 AM
Edited Aug 26, 2015 at 8:40 AM
Ok...I've grabbed 084 comskip which is supposed to have updated decoders and I've changed my setup to retain input files where it was deleting them after succesful conversion previously. I grabbed 4 shows from 08/19-21.....some hdtv content and some regular....I'm having to run each one by itself so the conversion gets all the cpu to mimic the original conversion but in the first one I tried it did not seem to improve anything...if anything it was a few seconds over on both the marking and the cutting....I'll be attaching logs as soon as the conversions finish.

I'm cancelling the "after" ones after comskip finishes so shouldn't be to long.

update The before and after log files of hardware decoding in comskip for 4 conversions are available here:

If you notice something obvious I'm doing stupid in the conversions please let me know but as far as comskip they didn't appear to help at all for these conversions. I should mentioned the transcodes were ran as "low priority" in mcebuddy so that might be a factor.

Input was HDHomerun HDHR-US2 mpeg streams recorded in 7MC to wtv and being converted to H.265 MKV.
Aug 28, 2015 at 2:04 PM
Edited Aug 28, 2015 at 2:05 PM
This is just a followup. I realized I had added all the logs to the previous post afterward so you would not have gotten notification the info was there. The comskip hardware decoding may still be of benefit to folks with a slow cpu but faster graphics card?
Aug 28, 2015 at 2:21 PM
That looks about right, with the 086 and our testing, we found no difference with mpeg2 and mpeg4 ASP video with / without hardware decoding (you have mpeg2)

with h.264 we found that comskip actually slows down by 4 times with hardware decoding enabed

Oct 15, 2015 at 11:04 AM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Marked as answer by rboy1 on 10/15/2015 at 3:04 AM
Oct 15, 2015 at 11:05 AM
Looking into this, some reason Comskip doesn't to support hardware decoding when running through Session 0 (kernel context), update will be posted in the work item created.
Nov 23, 2015 at 6:47 PM
With the latest 2.4.3 build added support for using Comskip's hardware decoder, this will need to be enabled by the user in comskip.ini by adding the parameter:


MCEBuddy will not automatically enable hardware decoding since it's performance varies drastically based on system configuration and in some cases can even reduce the performance. Hence the user will need to manually edit the comskip.ini file