Ive edited my post shpankey
but if you encode anything but x264 , like h265 or AVI etc your cpu will always be 100% , that’s normal , same with handbreak or any other if your cpu is low it means it’s changing container , mkv to mp4 so your not actually re encoding anything
Re encoding will make your CPU 100% no mater what and that’s normal nothing wrong with that
@TwistedEndz said:
Ive edited my post shpankeybut if you encode anything but x264 , like h265 or AVI etc your cpu will always be 100% , that’s normal , same with handbreak or any other if your cpu is low it means it’s changing container , mkv to mp4 so your not actually re encoding anything
Re encoding will make your CPU 100% no mater what and that’s normal nothing wrong with that
I don’t know… not sure I agree w/ this. Not saying I’m right here, but from my (limited) testing so far, adding h264qsv to the .ini file (per mdhiggins) definitely has the decoding/encoding being processed by Intel’s QuickSync, which is very fast and uses very little CPU. Which is kind of the whole point of it. Whether it’s worth it is the only question now… the trade off for low CPU and speed is quality. I just didn’t realize it would be THIS bad. Curious now if there are any quality options for h264qsv to make up for it.
@shpankey said:
Hey Cayars, another quick question… are you sure QuickSync is working correctly? I ran into a couple of posts about needing to add h264_qsv in the .ini file. btw, when I did this, it DEFINITELY worked, but the output file was pretty bad. It took a 6G file and created a 600meg file in it’s place, that was blocky and not very watchable. It definitely worked though, CPU % hovers around 13%.
h264_qsv allows it to use QuickSync or Hardware encoding. Depends on your environment how this is going to work out but for our puposes I would rather use software and get the best quality/file size as possible. Now on the other hand if we were doing real time transcoding then maybe hardware is fine.
If, for example, I don’t have that option listed in the .ini (even w/ the qsv = true) and I change the h264-max-level = 4.0, my CPU % is 100% on all 4 cores of the i7 770k CPU. Here, this will explain what I mean better hopefully…
With these options:
- video-codec = h264_qsv,h264,x264
- h264-max-level = [4.0, 4.1, doesn’t matter]
- use-qsv-decoder-with-encoder = True
…then low % CPU use. It goes fast too. But file is small (600meg from 6G) and looks awful.
h264-max-level should be safe to use at 4.1 these days. Just about any device worth using will support it.
Looks crappy because of the QuickSync setting. If you use this you need to adjust other settings as well but you probably don’t want to use hardware for our purposes.
If you want to play with QuickSync just duplicate the “Convert” directory to Convert2 and play there.
With these options:
- video-codec = h264,x264
- h264-max-level = 4.0
- use-qsv-decoder-with-encoder = True
…then MAX % CPU use.With these options:
- video-codec = h264,x264
- h264-max-level = 4.1
- use-qsv-decoder-with-encoder = True
…then low % CPU use most of the time, but I’m not sure if it’s b/c the file is already 4.1 and so it’s just changing containers (?) and not re-encoding is why (that’s my guess is what’s happening)Thoughts?
You can tell what it’s doing. On screen in the video section you will see “copy” if it’s just remuxing. This would be the case if the file was already 4.1 and your present setting is 4.1. Less CPU this way. Just as these two examples show.
@shpankey said:
@TwistedEndzIs the Python path added to your environmental variables?
I would also do this from just a normal regular command prompt. I’ve had issues w/ powershell and elevated command prompts on Win 10. Seems quirky sometimes.
When you install Python there is an option to add to the path but if memory serves me correctly it’s not the default.
@shpankey said:
Found this post, so it seems it does need added…use intel quicksync · Issue #431 · mdhiggins/sickbeard_mp4_automator · GitHub
mdhiggins commented on Mar 4, 2016
Just pushed an update to add the h264_qsv codec as an option.
Update your autoProcess.ini settings to the follow:
video-codec = h264qsv, h264, x264Give it a try and let me know if its working
Going to do some testing w/ your and his w/ that enabled. Curiously, I had used: h264_qsv before and it worked, he says to use h264qsv instead. He probably catches both options, I’m sure.
Hopefully my others posts have covered this option. Older Intel CPUs won’t look as good as newer Intel CPUs so I didn’t want to make this the default. Plus you may need to change a few other options to get it working well. Now right or wrong things to do as it depends on each system what is going to work best.
Yup, you explained it very well. Thanks! I didn’t realize after all this time about the “copy” thing… see, learn something with every post of yours. 
I’m in agreement, the tradeoff is way too much. I’ve went back to software, as you said, for our purpose, it’s definitely the best.
Hey Cayars, I know you said most devices use 4.1 now, do you know if the Fire TV (gen 1 and 2) and Fire Sticks (1 & 2) now also use profile 4.1 by default in plex now? I have about 6 devices connected w/ those and I thought they were using 4.0 (triggering a transcode on 4.1 material). Just want to confirm before I switch up to 4.1
Technically 4.0 is what they support. However the main difference is the maximum bitrate of 50 vs 20 megabits.
What we often see is video encoded by something like dvdfab or handbrake and it will mark it as 4.1 even if the bitrate is under 20Mb.
I bet you can still play any 4 or 4.1 if the bitrate is not over the limit. I don’t have any Fire device to test with.
If the file is really a 4.0 file but marked as 4.1 it would suck to convert vs copy the video. At present the code uses what is marked in the original file. I may be able to overdue this wirh some addition logic and make it experimental.
In the mean time can you try playing some 4.1 videos around or just below 20Mb to see how these work for you? This will help us determine how to proceed.
Plex app on the Fire TV does allow the user to change max H.264 Level. I have two devices and have it set for 4.1 (most of my media was/is 4.1) Originally, the Fire TV didn’t check level and playback worked fine (at least for me). They added the level check several months after the app was introduced.
Great to know. Is the default 4.0 in the GUI?
Yes, at least on the Gen1 and Fire Stick I have.
Cool, so that solves it for the 2 I have at home here… now to call the people w/ the other 4. They’re very untechnical… but to DP on 4.1 will be so worth it, as that seems to be the vast majority now.
Quite surprisingly, Fire TV 2 in the kids room, it was defaulted to 5.1 (recommended) :wow: Couldn’t check the Fire TV 1 in the other kids room as they were in there asleep, but will check 2mro.
Wow even better! Your friends should not have a problem with 4.1 setting.
The few posts I made earlier were from my cell phone driving home. Now that I’m home, here is the link I was using to get info from: https://developer.amazon.com/public/solutions/devices/fire-tv/docs/device-and-platform-specifications
MP4 - “Hardware accelerated up to 1080p @ 30fps or 720p @ 60fps, 20 Mbps, High Profile up to Level 4”
Sounds like they should update their documentation!
No doubt! All aboard the 4.1 train… whoo whooo. lol This is an awesome development.
So glad you decided to recommend we all move to it now, should make for less re-encoding/more direct playing in general.
On another note, I tried the script locally on the PC that I’m switching over to tomorrow (w/ i7 770k @ 4.8Ghz), it absolutely FLEW! It seems going through the network to the iMac’s RAID box definitely took a huge toll on overall time. Oddly enough, things like subtitles take forever this way… also, the MOOV bit at the end also took forever. But when done locally, it does the subtitle in ~1 second and the MOOV bit in just a few seconds. This will dramatically speed up the entire process for me by eliminating those long delays.
I didn’t like running the script on the little iMac cause it’s hosting Plex, SABnzbd, Sonarr, Radar & Transmission servers, and I need the CPU for Plex transcodes. So I would run it on the PC to a networked shared drive (RAID box on the Mac). It was starteling just how much faster it flies through these files, not only for the time saved on the above, but also copying/re-encoding is way faster for obvious CPU reasons. I should be able to re go through the entire library in a few days now.
I sort of do the same thing and have other computer do my processing, then I move the results to the Plex server. I try and keep that server strictly for FTP and Plex.
I have a 2nd computer (old xeon) that I’m running Plex on just for the DVR service. I will run MCEBuddy on that computer but then still take the results of that and run it through this script to make sure I’ve got AAC audio, web optimized (moov atom up front), etc just for consistency sake. Of course this is pretty fast once the file is moved across the network from DVR to processing computer then to Plex Server.
Carlo
could someone help me as to where I can get the module rebulk.introspector? This error won’t let the conversion work, and I have googled this without any success…Thanks
@buckeyesfan said:
could someone help me as to where I can get the module rebulk.introspector? This error won’t let the conversion work, and I have googled this without any success…Thanks
Can you get a screen shot of this?
@buckeyesfan said:
Now getting this message:
Have a look at the file with MediaInfo and see if this file has a video stream in it. I’ve seen this before with corrupted video files.
