Has anyone experienced a huge CPU drain by FMLE 3 - going to over 90% (and sometimes 100%) which is causing jerky video capture and audio skips.
I'm encoding at a lower level of 500 kbps for video and 32 kbps for audio with VP6 and the capture to hard disk is so very jerky.
FME 2.5 works great at the same settings on the same machine and doesn't use more than 55% of CPU resources, with a very clean capture. I've gone back to using 2.5 till I can figure out what's going on with 3.0/3.1
Why is FMLE 3/3.1 such a resource hog? Any help and advice would be much appreciated.
My system specs are:
Core2Duo Laptop 2.0 gHz with 4GB Ram
Windows 7 Home Premium 32 bit (and 64 bit)
Input size: 720X480 (from the DV Camera)
Output size: 600X400 px
Video Bit Rate: 500 kbps
Audio - bitrate: 32 or 48 kbps - MP3 Mono 22,450
Codec settings: default
Device used: Sony camcorder via Firewire port to laptop
Laptop: Dell Core2Duo 2 GHz with 4 GB ram Integrated graphics adaptor using 348MB of the ram memory and Windows 7 32 and 64 bit versions.
Yes, same settings are used for both tests in the 2.5 and 3.1 versions, both on the same machine.
Same exact content in both - me speaking into the camera.
FME 2.5 uses 48-58% of CPU resources - nice clean capture to an FLV file on the HDD
FME 3.1 uses 85-99-100% of CPU resources - jerky capture with dropped frames and skipped audio
Question: whatever the settings used may be, its the comparison with v.2.5 that shows 3.1 is a resource hog since both tests are done on exactlty the same equipment, with the same settings and the same content. That is obviously a 3.1 version issue right?
Are you sure that the input and output sizes are same in both 2.5 and 3.1?
Could you please compare 2.5 and 3.1 by keeping the input and output sizes same in both? Keep input and output to same 720x420 size and compare the CPU usage.
Let me know the result.
OK - here's where it stands with both input and output size set the same (720X480) and all other factors remaining constant as before:
CPU resources used when not recording: 15-17%
CPU resources used up while recording: 40-50%
CPU resources used when not recording: 15-20%
CPU resources used while recording: 75-85% (peaking occasionally to 95%)
(still 25% more than v.2.5 but manageable).
Does this mean that I am always forced to stream and the larger output size?
Here's another variation of the test with v.3.1 ...
Input size: 360X240 Output size: 720X480 - CPU used: 98% !!!
Input size: 360X240 Output size: 600X400 - CPU used: 72%
(What's the implication of using a smaller input and larger output size? How would it affect the quality of the end result video?)
Input size: 360X240 Output size: 360X240 - CPU used: 22% !!!
Input size: 720X480 Output size: 360X240 - CPU used: 50%
Input size: 720X480 Output size: 600X400 - CPU used: 90-95%
Input size: 720X480 Output size: 500X334 - CPU used: 75%
(Unfortunately Input sizes are fixed by fmle and cannot go between 720X480 and 360X240)
Note: despite the interesting results of the input/output tests, its still evident that 3.1 uses 25% more CPU resources than 2.5, making it the less efficient of the 2.
Actually, fmle doesn’t restrict the input sizes; it shows only those sizes, which are supported by the selected device.
I would suggest you to "not resize" unless that is absolutely necessary because of your output size requirements. Not resizing produces better quality and gives better performance. Regarding performance and quality while resizing I can mention 2 points:
1. For a given output size, on increasing the input size, overall CPU usage by FMLE increases.
2. For a given output size, quality improves on increasing the input size.
You were using Vp6. Try the same tests with H.264 codec and see the difference.
I noticed a modest improvement with H.264 - from 75% the CPU usage dropped to about 70% (input and output the same at 720X480)
This is odd because I thought H.264 required more processing power than VP6 (?)
I also assume that my laptop (Core2Duo) will work better with FME 2.5 so I think I should stick with that till I upgrade to a Core i7 system with a dedicated graphics card instead of an integrated graphics like I have now?
Thanks so much for all your patience, help and advice - much much appreciated!
Found out what was causing the slowdown and high CPU usage - caused by selecting different input and output sizes. However, the question of why fmle 3.1 uses 25% or more CPU resources than the older v.2.5 still remains. Hopefully future versions of fmle will address this issue.
Can you please check output FPS by both FMLE 2.5 and FMLE 3.0.
Actually in FMLE 2.5, resize filter was single core resulting in lesser output FPS so in FMLE 3.0 resize filter was improved to use multicores resulting in more CPU usage but more Output FPS.
if you dont use Resize filter than performance of FMLE 2.5 and FMLE 3.0 should be same but if you are resizing Video then FMLE 3.0 will use more CPU but results in more output FPS.
Can you please share the snapshot of FMLE statistics for 2.5 and FMLE 3.0 to confirm this.
Also in FME 2.5 VP6 encoder was single core resulting in lower FPS and than in FMLE 3.1. Steram should be more smooth when you compare output stream from FMLE 2.5 and FMLE 3.0 or above with VP6.
With H264 experience should remain same when no resize is involved
I have been pulling my hair out for two days on this same exact issue! I've learned a few additional things, so I figured I'd add it here in case in helps someone or someone can use it to help me.
I am experiencing the same problem of maxed out CPU usage on two machines using either 3.1 or 3.2 (same with both). One machine is a Core Duo and the other is a Core i7 (Q 720 @ 1.6 GHz each). It's crazy that it even maxes out all 8 CPU threads (hyperthreaded dual duo cores!).
Here's what I learned:
1. Doesn't matter between H.264 and VP6.
2. Upon Reboot, you can get about 5 minutes of encode before the CPU jumps to high 90s and causes stuttering encode.
3. Core thread usage continues to increase.
4. If the output is the same size as the input, the CPU usage will remain stable. If however, you change the output size (resizing) then the CPU will begin to spike. If you stop it before it gets too high, and restart it with the size the same again, it will stay stable, but not drop back down to where it was before (meaning that FME is not letting go of the CPU threads it started using when resizing?).
5. If I use the webcam as the input source (640x480) and resize to a 16:9 frame size, I can encode indefinitely without going over 20% CPU, it's only if I hook up a camera via Firewire that I max the CPU out.
6. Elevating the priority in Task Manager of the FME process has no effect.
I hope this can be addressed, as it's obviously some kind of a problem. A Core i7 computer should be good enough to encode and resize video! For now, I will have to revert back to 2.5, which runs fine.
I just plain gave up and reverted back to 2.5
Emailed Adobe tech support about it but got no response (as usual).
Pesi A. Unwalla
Streaming Video to MakeYour Website Stand Out from the Rest
MediaPower New Media Communications
You don't pay us just to shoot a video or build a website...
You pay us to design your business communications to convert viewers into
Europe, Middle East and Africa