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

AMD --> Intel Z77 platform, transcoding times more than doubled?!

Jun 26, 2013 at 8:46 AM
I recently upgraded my motherboard, CPU, and RAM, and the effect on MCEBuddy has been quite unexpected.

Old:
Asus M2N82 Deluxe (AM3)
AMD Phenom II X4 965 BE
8GB DDR2-800 RAM

New:
Gigabyte GA-Z77X-D3H (LGA1155)
Intel Core i5-3470K
8GB DDR3-1600 RAM

I carried the existing installation of Windows forward by removing all the motherboard hardware dependencies. The result of this has been that transcoding times in MCEBuddy have increased dramatically rather than decreased as I expected. At the moment it's transcoding a one-hour HD program (5GB) and the estimated time to complete Pass 2 is approximately 8 hours (originally it showed 19 hours!). That is at least double the time required with the AMD system, which reputedly has inferior per-thread performance compared to this new Intel one.

Have I overlooked something, done something wrong? What could be causing this and what procedure can I use to troubleshoot it? Was my expectation of better performance just terribly misguided?
Coordinator
Jun 26, 2013 at 4:05 PM
AMD core is more powerful than Intel Core since video conversion is heavily dependent upon floating point operations. That's my understanding.

http://www.cpu-world.com/Compare/411/AMD_Phenom_II_X4_960T_vs_Intel_Core_i5_i5-2500K.html
Jun 26, 2013 at 4:46 PM
Great... so the switch is saving me lots of power-per-second (30W or more at all times even with more platter drives) but I'll be paying for it when transcoding takes twice as long as before? And I paid significantly more for the motherboard and CPU than an 8-core AMD AM3+ upgrade?

That can't be right. Doesn't the Intel platform have some optimization specific to video transcoding or encoding/decoding? I can't recall the name but could swear I read about it while I was evaluating making the switch.
Coordinator
Jun 26, 2013 at 4:53 PM
if you're referring to hardware encoding they have a special SDK which programs need to use and for now expect handbrake (which is BETA) no other underlying software utilizes it.So it won't make any difference on regular programs


Jun 26, 2013 at 6:00 PM
I agree with the OP, that there is a significant enough gap in pure processing power that there should have been a decrease in the processing time, or at least it should have been in the same ballpark. While AMD is indeed better at FlOps than a directly comparable Intel part, those two processors are not directly comparable, especially with the jump from DDR2 to DDR3 RAM.

To the OP:

I have some bad news. Windows does not do well with swapping from one processor manufacturer to another. I'm honestly slightly surprised that it started at all, as I've had Windows bootloop when changing motherboards in the same family, let alone to another chipmaker.

As I understand it, during the Windows installation it gathers various data about your system, then optimizes itself to what it finds. While minor updates won't have much negative effect, major updates will often cause it to become unstable, and for the hardware to severely underperform, especially when pushed to its limits by things like HD video conversion. Essentially, Windows is extremely confused, because what it was doing doesn't work the way it expects it to, which causes it to take extra time.

So, my advice is to save an image of your current installation (a true 1:1 disk image, not a backup) just in case something goes awry, and start over. You will probably spend more time trying to troubleshoot it than simply wiping it and reinstalling/reconfiguring the OS.

Congrats on the new hardware though, once you get it working it should be some nice kit.
Marked as answer by rboy1 on 2/11/2014 at 7:53 PM
Jun 26, 2013 at 8:10 PM
As an aside, I've been trying to estimate these completion times by just observing the main window, but that's not exactly the best way, is it? Is there some place where MCEBuddy records the completion times for all jobs, either in total or per phase? I looked in the main log file, and though I could try to extrapolate that from the timestamps it might still not be very useful if there were interruptions (down time for any reason).
Coordinator
Jun 26, 2013 at 8:19 PM
onlyway to look at it is through the convresion log timestamps.


Jun 26, 2013 at 8:26 PM
sobs

Might I suggest some sort of "conversion history" as a future addition? It would prove useful to troubleshooting when something begins to affect transcoding to see exactly when the effect began. Not that every job of the same size file or program length takes exactly the same time to transcode, but you'd get a good enough sense of what's "normal" from looking at such a history, such that a change would begin to stand out.
Jun 26, 2013 at 9:10 PM
And it could be that I was wrong entirely... my sample size of one might have been entirely the exception. I'm looking at another job now of another hour-long program from the same channel (PBS), file size is comparable too, and it's already halfway through Pass 2 and saying there's less than an hour left on the clock to finish. I had started watching it when the job started and was trying to pay attention when Pass 1 completed to see how Pass 2 would progress, but I got distracted for just a while and it's already halfway done.

Really need that history feature... and more patience. :->
Coordinator
Jun 26, 2013 at 9:10 PM
i dont understand what you're looking for. There is a conversion log, There are debug levels and there is a conversion history window which shows the status of each conversion.


Coordinator
Jun 26, 2013 at 9:30 PM
still have no idea what you're asking for. You haven't stated your requirements.


Jun 26, 2013 at 9:32 PM
Edited Jun 26, 2013 at 9:33 PM
I thought I'd explained it well enough: a simple historical list of all the completed conversion tasks, with the beginning date-time, name of the job or program, the total computational time required (i.e. adjusting for down time etc. if possible), and perhaps also the times for each phase; a list that starts with the first job and grows from there. It could be a simple text file. As far as I can tell the program already has the information required to maintain such a list, aside from a bit of timestamp math to derive the totals. None of the existing things you mentioned make that information so readily available.
Coordinator
Jun 26, 2013 at 9:45 PM
got it. open a feature request on the issues page and ill look into it.


Coordinator
Jun 26, 2013 at 9:47 PM
right now if you look at mcebuddy.log you can get the start time and completion time for each conversion


Jun 26, 2013 at 10:09 PM
Edited Jun 26, 2013 at 10:12 PM
I saw that. When I looked at the log file for the entries about the job that prompted this post, I did find them, but what I found was what concerned me: the elapsed time was from 5:30pm yesterday to 4:51am this morning. I didn't know whether it really took that long to actively process or whether external events had interfered with the job and either stopped it completely for a time or slowed it to a crawl. If there was an explicit history that could factor out externalities and show actual time-spent-computing, that would be valuable. Plus having that summarized in one place for all jobs would be especially useful.

I'll try to get it written up as a feature request if it's do-able.
Coordinator
Jun 27, 2013 at 3:39 AM
im including some performance metrics in the next rlease but they will be at the conversion log level and a summary i n the conversion history. it shows elapsed time, that the only one that can be calculated. Time spent will depend up on priority, other processes, number of simultaneous conversions and also number of CPU cores used.


Jun 27, 2013 at 3:53 AM
I think that should be useful in the long run. I wasn't sure if anything more than elapsed time could reasonably be determined. Meanwhile, the more I watch new jobs in progress the less I'm worried that this new system isn't meeting performance expectations. In general it seems the jobs in fact are completing faster than with the old system, and that first job's exceptionally poor progress was caused by something other than basic hardware performance. I'll just have to watch for repeats of that poor performance and try to identify a pattern of external factors.
Oct 3, 2013 at 11:23 PM
VulcanTourist,

There was recently a thread describing how to utilize QuickSync for Intel CPUs. The link is below.

https://mcebuddy2x.codeplex.com/discussions/444131

Hope this helps, I am on my first 2 conversions, we'll see how it goes.

Greg
Oct 4, 2013 at 12:06 AM
Greg:

Thank you for pointing that out! I haven't been keeping current with MCEBuddy and didn't see that. The transcoding efficiency with my Intel hardware actually hasn't been bad at all since my initial observation, but GPUs have a certain knack for this sorta thing that shouldn't be wasted.
Oct 4, 2013 at 12:11 AM
And, I have used QuickSync in other products. It can be amazingly fast.

rboy1,

I have noticed that MEncoder has a similar switch for NVidia GPUs, I tried going through their documentation and couldn't find how to implement it. I would love to shave any time off I can as well. Think you can help a brother out there too? I know you're busy and all.

Thanks,
Greg
Coordinator
Oct 4, 2013 at 12:35 AM
which mencoder are you using? last I heard mencoder stopped development in 2011
Coordinator
Oct 4, 2013 at 12:45 AM
also as far as I know only mplayer support hardware decoding. if you know of mplayer supporting hardware encoding do let me know


Oct 4, 2013 at 12:58 AM
0.0.9.0

1.1.1 was released 5/5/13.... but it looks like that is Linux only.

There is a sourceforge project for the Windows version though...

http://mplayerwin.sourceforge.net/

The version of MEncoder is 1.1.1
Oct 4, 2013 at 1:40 AM
I will try to find out more.

The executable is apparently 64-bit, which would be nice.
Coordinator
Oct 11, 2013 at 1:58 PM
sorry folks the latest version of mencoder does not even work, it hangs on most conversions. Don't know what they did, but they broke it.