|
|
| Barnister |
| Posted: Dec 13 2011, 11:02 PM |
 |
|
Advanced Member
Group: Members
Posts: 54
Member No.: 27261
Joined: 22-March 10
|
2 years ago, I found my perfect settings for me to encode my gameplay videos: http://www.donsalva.com/2009/03/01/virtual...ettings-youtube .
Now, I'm writing a short opinion on my blog about how Intel's new CPU 2600k benefits me.
However, 2 years I'm doing it, and still the very basic question I cannot answer with certainty. Here's a short snipplet from the blog entry I plan to publish soon.
| QUOTE | Encoding speed is measured in (average) frames per second. The more, the merrier. It's also important to know that there are, what I like to call, "motion-heavy" and "motion-light" scenes.
This is, like the name suggests, a scene in game (or anywhere for that matter, but I'm talking video gameplay specifically here) in where there's either very much motion / moving happening on the screen or the opposite. Why is that important you ask?
Motion-heavy scenes take much longer to encode than motion-light ones, at least that was my experience in those 2+ years since. I might of course be totally wrong about this, and unfortunately I don't have hard statistics to show for, i.e. benchmarks while encoding. Just my observation, unfortunately. |
Yes, of course there are many more factors that influence how long it takes the same scene to encode, but I don't want to get too technical. Am I right about the motion-heavy/motion-light distinction? |
|
| dloneranger |
| Posted: Dec 14 2011, 07:28 AM |
|
|
Moderator
Group: Moderators
Posts: 2366
Member No.: 22158
Joined: 26-September 07
|
It's down to the codec used for encoding, and the settings used in it
It's right more often than it's wrong
Motion search can take longer if the thing it's looking for has moved a long way from one frame to the next
It's a normally a changeable setting though, from 'none' to 'try really hard to find it'
And not all codecs do motion searching, uncompressed and lossless like huyyf and lagarith come to mind, so motion isn't a factor for them at all
So, you'll always find someone who can contradict you
--------------------
MultiAdjust JoinWav WavNormalize FFMPeg Input Plugin v1827 UnSharpMask
Windows7/8 Codec Chooser
All FccHandlers Stuff inc. Installers for acm codecs AAC, AC3, LameMp3 |
|
| Barnister |
| Posted: Dec 14 2011, 08:23 AM |
|
|
Advanced Member
Group: Members
Posts: 54
Member No.: 27261
Joined: 22-March 10
|
Well, the codec is Komisar's x264 http://komisar.gin.by/ and the settings are http://www.donsalva.com/blog/wp-content/up...ub_Settings.jpg . |
|
| dloneranger |
| Posted: Dec 14 2011, 02:33 PM |
|
|
Moderator
Group: Moderators
Posts: 2366
Member No.: 22158
Joined: 26-September 07
|
In general for your setup then, yes, the further something moves between frames the longer the encoder would take to find where it had moved too (or finally give it if it's moved out of range etc)
--------------------
MultiAdjust JoinWav WavNormalize FFMPeg Input Plugin v1827 UnSharpMask
Windows7/8 Codec Chooser
All FccHandlers Stuff inc. Installers for acm codecs AAC, AC3, LameMp3 |
|
|
