This project has moved. For the latest updates, please go here.

slow framerates

May 22, 2014 at 8:55 PM
Edited May 23, 2014 at 3:56 AM
I am running on an i7 860 @2.80 with 8gb ram and windows 8.1.1 64 bit and i am experiencing very slow encode times. My graphics card is an AMD HD 6800 and I can see that opencl is true. I am including a log of both normal mp4 and mp4 with the -p setting. What am I missing here?

BTW I cropped the orginal wtv file from 2 hours to only 3 minutes just to save time before I added to be converted.

https://www.dropbox.com/s/ni94ippt9wup1he/with%20-p.log
https://www.dropbox.com/s/2mfvpyp12odgbps/without%20-p.log
May 23, 2014 at 3:56 AM
Ok so after installing on a slower computer (i5) with QuickSync and opencl I see that my framerate has increased by about 30% which in turn makes the total conversion time about 30% less. I had no idea that an intel video with quicksync would be faster at hardware encode than a dedicated GPU that is much faster for gaming and graphics editing. So now here is the question. The CPU i was testing with has intel graphics 4000 with quicksync is an i5-3570 @3.4.

If i invest in a i7 4470 @3.40 with an quicksync compatible intel graphics how much will that increase the overall speed of the encoding? Since this is about a $500 investment (because I would have to buy a new motherboard as well) I want to be as certain as possible that it is worth it.

Am i correct in assuming that the numbers in the article https://mcebuddy2x.codeplex.com/discussions/543814 which if I read it correctly state that a source wtv video that is 1hr 5min long at 1080 will convert to mp4 normal in 17 minutes? Because if that is correct then that is a decrease of about 1 hour that my current setup takes.
The source video I am testing is about 1 hour long and about 4.82gb which i assume is similar to the one you benchmarked.

Could I expect it to take about 17 minutes to convert a 1080p 5.1 wtv file to mp4 normal if I make the investment as described above?

Thank you for your time.
Coordinator
May 23, 2014 at 4:15 AM
please attach your conversoin log zip to analyze the performance. Yes QuickSync is the faster way, OpenCL is currently an accellerator and not converter yet.

The test machine used was a Core i7 Ivy Bridge processor (2nd Gen) using the HD Graphics 4000 chipset. If you're investing in the HD Graphics 4600 you should see slight better performance numbers over the benchmark. I don't think you will see a significant difference between the 2nd gen and 3rd gen processors.

After seeing your logs I can advise on what potentiall might be slowing your conversion down, it could be multiple factors from qualty, resoution, format, etc.

See this for more details:


Coordinator
May 23, 2014 at 2:11 PM
rumred85 wrote:
I am running on an i7 860 @2.80 with 8gb ram and windows 8.1.1 64 bit and i am experiencing very slow encode times. My graphics card is an AMD HD 6800 and I can see that opencl is true. I am including a log of both normal mp4 and mp4 with the -p setting. What am I missing here?

BTW I cropped the orginal wtv file from 2 hours to only 3 minutes just to save time before I added to be converted.

https://www.dropbox.com/s/ni94ippt9wup1he/with%20-p.log
https://www.dropbox.com/s/2mfvpyp12odgbps/without%20-p.log
I don't see -P in any of your logs. Did you modify the correct profile?
Also assuming you've seen this thread https://mcebuddy2x.codeplex.com/discussions/530808
May 23, 2014 at 2:53 PM
Yes I read through the thread yesterday and got the suggestion for the -p. Based on the suggestion I added at the end of the following line:

handbrake-video= -e x264 -b 1400 -x me=hex:trellis=1:subq=8:partitions=all:8x8dct:ref=3:rc-lookahead=50:keyint=25:keyint-min=20:bframes=1:weight-b:level-idc=40:b-pyramid=normal:direct-pred=auto:mixed-refs:deblock=-1,-1:nofast-pskip:nodct-decimate:b-adapt=0:threads=auto -p

This was under the mp4 normal section of profiles.conf

Thank you for your help.
Coordinator
May 23, 2014 at 3:17 PM
the log does not show the flag was added, so I'm guessing it was added to the wrong section or didn't save properly. Check it again, try and upload the new log.

this is what the log shows reading from the profile
--> handbrake-video=-e x264 -b 1400 -x me=hex:trellis=1:subq=8:partitions=all:8x8dct:ref=3:rc-lookahead=50:keyint=25:keyint-min=20:bframes=1:weight-b:level-idc=40:b-pyramid=normal:direct-pred=auto:mixed-refs:deblock=-1,-1:nofast-pskip:nodct-decimate:b-adapt=0:threads=auto



May 23, 2014 at 7:33 PM
Ok I tried it again and got a much larger log file.

https://www.dropbox.com/s/8f3dexwephypg27/retry%20with%20-p.log

Thanks for checking.
Coordinator
May 23, 2014 at 10:43 PM
That's because you broke handbrake and it fell back to ffmpeg.

It is -P and not -p. Case matters

Marked as answer by rboy1 on 5/24/2014 at 9:54 AM
May 23, 2014 at 11:06 PM
Sorry I had no idea case mattered. I fixed it and the log is more normal size now

https://www.dropbox.com/s/8f3dexwephypg27/retry%20with%20-p.log

Thanks again.
Coordinator
May 24, 2014 at 12:23 AM
As you can see from the logs there is a 30% increase in the FPS from your original logs.
Original was 30fps and the new log are 40fps. So -P is working great for you.
Overall it good I usually see between 20-30 FPS without hardware.

With quick sync depending upon the configuration and hardware it can be anywhere from 75fps (high quality) to 1400fps (low quality)

May 24, 2014 at 12:28 AM
Thank you for your thoughts on this....you have been a big help. One more quick question. Is the quality of quick sync better than opencl? I know this is not hard and fast but just as a general rule what is your opinion of quicksync vs opencl vs software encoding?
Coordinator
May 24, 2014 at 3:08 PM
Please see the quick sync link above. There is always a trade off. It depends upon the bitrate. Like for like there is a small difference but it usually visible to the naked eye at higher bitrates (1.5M+). Best way to encode 2 videos with and without and compare them all other params being equal

Coordinator
Sep 1, 2014 at 5:49 PM
Folks who were facing a slow fps issue with hardware encoding (about 30fps), try the new build of mcebuddy it'll speed it up to around 150-200fps with the new 2.4.1 build. This was due to a intermixing of software and hardware deinterlacers which was slowing down the encoder. Now it uses only hardware deinterlacer.
Marked as answer by rboy1 on 9/1/2014 at 10:49 AM