This forum software has now been archived into static HTML page (i.e. it does not function as a working forum anymore, so you cannot login.)

In due course a new forum will be available to help support newer CamStudio versions.

Sorry for the inconvenience and thank you for your patience.

'Actual Input Rate' Very Low

I'm new to CamStudio, so bear with me. Through this forum and YT vids, I've managed to get CamStudio past several initial problems. However, one problem persists and I don't have a clue how to fix it.

Environment:
* CamStudio v2.6 r294
* Windows 7 Home 64-bit
* Intel i5 760 CPU with 4 GB of memory
* ATI Radeon HD 4550 adapter
* Jawor's xvid codecs

I've run tests with only Task Manager and CamStudio running. Results are disappointing, for example:

CPU Usage, Memory Usage, SKE/CFE/PBR, Actual Input Rate
--------------------------------------------------
20%, 47%, 20/5/200, 13 fps
20%, 45%, 20/25/40, 9 fps

I've tried capturing full screen, window, and region, with audio recording on and off, without a great difference in the results. Any suggestions are appreciated.

Clayton

Comments

  • edited October 2012
    This has been bugging me as well, so I finally did some tests and more than doubled my actual capture rate.

    The biggest secret was in changing the monitor screen resolution to 16-bit instead of the default 32-bit color. 16-bit is the "16 million colors" setting we all used to know and love before 32 bit came along. 32-bit color actually is 24-bit color with an additional 8-bit alpha channel that controls transparency (used for transparency effects in Aero). In 16-bit color, you sacrifice the transparency effects, but I would challenge you to see the color difference except in extremely flat colored regions with very subtle gradients in them.

    I made a video and uploaded it to YouTube to show the test and where I made the change. Find it below or in this playlist:

    There are other settings that can affect the video capture rate, but changing from 32-bit to 16-bit color is the most radical and easy to do. Mind you, I'm pushing CamStudio as hard as I can in these tests - you'd have to convert to a slower FPS to make these recordings work on many media players. But that's a different issue.

    Terry



  • edited October 2012
    Thanks for the vid Terry!

    In my case, however, changing from 32-bit to 16-bit color resulted in a actual input rate change of 13 fps to 19 fps. Not very helpful.

    For my application, I really need at least 25-30 fps to accurately capture video playback. Otherwise, people in videos look like stuttering ventriloquists.

    Just don't understand. I've seen YT vids demonstrating 100fps, but I can't get anywhere near that. Of course those demos were using v2.0 and lossless codecs, which I thought were supposed to be low performers.

    I've even checked GPU usage and it's low as well. It is not obviously a resource issue. I have a mid-range graphics card (Windows Experience Index - Graphics 4.7 and Gaming graphics 6.1 out of 7.9) - perhaps that's an issue. Don't know whether CamStudio depends on adapter performance. Just can't identify a clear source for this problem.

    Another question. In the main CamStudio window while recording, there's a parameter cited 'Limited recording: On 1750 ms'. This is visible in Terry's vid as well. Could that be a factor, and if so, how do you turn it off?

    I'll keep searching, but I'm beginning to lose hope for CamStudio...
  • The "limited recording on" item is a glitch in the program - it is off, and it only designates a timer-limited recording length when it is on.

    That is astonishing to hear you got such a small return on changing the setting - but I'll bet I know why. You have to re-start CamStudio entirely once you make the change for it to pick up the new setting.

    Let me know if that was your situation.

    Terry
  • edited October 2012
    image

    Sorry, but CamStudio is reporting 16-bit color and 19 fps (SKE/CFE/PBR @ 20/5/200).

    Other thoughts?
  • Oh well... just thought it was a possibility, as mine required a re-start of CamStudio.

    I do know without a doubt that trying to record 1080p videos will be very difficult for any system even with amazing hardware. Can you settle for 720p recordings? (1280X720) That's what I did my tests with.

    Terry
  • Just a few observations here ....

    This problem seems to come up when trying to capture large areas, usually full screen with large monitors. It's most likely caused by the graphics processing being overtaxed, but I'm not sure how and why that affects Cam. You should do a test with a 640 x 480 capture area to use as a comparison. By all means you should check Task Manager to see what's running before you try recording (shut down Adobe Flash and any AV programs) but do NOT leave Task Manager running when doing the test. With nothing else running, your input rate should be around 70 with that computer, assuming that you are capturing nothing but your desktop and the Cam interface.

    BTW you can shut down your monitor for the last half of the test and view the result. The input rate captured on the Cam interface should not change when the monitor is shut down.

    You can then try a test running the program whose generated image you are trying to record, but capturing just a 640 x 480 portion of the screen as you did with the first test. If the input rate drops dramatically, it's caused by whatever is driving that program (hogging graphics resources), and if it doesn't, the low input rates are caused by the large capture areas you've been attempting.

    The simple workaround for the too-large capture area, is as Terry suggests, to simply capture a smaller area. The resulting video may be upscaled using a video editor, or simply be displayed full screen when viewed. When capturing anything like streaming video, you should note that the source files rarely exceed 360, so using your computer's graphics to enlarge to full screen is almost always pointless and often does nothing other than degrading the image while taxing the graphics resources for no useful purpose.

    There are other factors which can alter how smooth the motion is on the finished video, but getting the best capture possible is the necessary starting point.

    Ken
  • edited October 2012
    Thanks, Ken - great input to this!

    Digiday also did some tests a couple years ago, and his test video can be found here:



    The best results were from Lagarith Lossless in his tests, but the length of time available with a lossless codec is quite short - 9 minutes max in 32-bit and 11 minutes max in 16 with a 1280X720 pixel region was what I got. You can, of course, record many short clips and glue them together in an editor, but that's pretty un-useful for game-play videos.

    Though CamStudio was originally only designed to record tutorials (powerpoint slides or software screen shots with speech), it has been able to do some game-play and high-motion captures lately with the improvements to hardware that have come down the pike in the last ten years. But it still is not exactly a killer app for doing this kind of high-motion capture unless the hardware is amazingly high quality, it seems. And the results vary like mad depending upon the resources being taken up by other programs and which resources those programs are being greedy for.

    I'm going to continue this testing - in search of the holy grail of capture settings and codecs -- and will produce a video like digi's later on. Meanwhile, any tests people would like me to perform can be placed as suggestions into this thread.

    Terry
  • Thanks to everyone for their feedback...

    Just an update. It appears the low fps is more a CamStudio issue, rather than a hardware issue.

    Using BB Flashback Express, I can record 1080p, 32-bit color, 30 fps, with sound on my hardware.

    I'll be testing FreeSeer next...

    Clayton
  • Now I'm beginning to wonder if we're talking about the same thing when we're discussing frame rate. We have input frame rate and we have FPS, which is the actual rate at which a video plays. I've done quite a bit of testing using BB flashback, and what I found was that the frame rate was never close to what's needed for good playback. It doesn't matter that the FPS (play rate) is 30, because that's nothing but the output, which can commonly be anything up to 200 with whichever recorder one uses. The issue is what one's graphic processor is able to produce for capture. If that is very low, say 9 FPS, a 5 MS capture rate will stlll grab the same number of frames, but it will result in a video with high VOB repetition, which results in less than smooth motion. I can't say that I can recall BB Flash giving one any way of knowing what the input rate is. What you're getting is a video with an undetermined capture rate playing at 30 FPS. I can estimate that what I get with Cam set at a 5 MS capture is effectively about 15-20 MS, the drop being caused by the limitations in my graphics processing. Generally speaking, I can set the output FPS to 25 or 30 with no noticeable difference between the two. BB Flash has its own processor, so it's converting to the desired FPS, while Cam needs to be set to a given FPS (40/25 would be 25 FPS) or converted afterwards, which is always the better choice.

    Ken
  • Let me clarify. What I'm really talking about is probably better termed 'capture rate'. For example, let's say I'm capturing a desktop with a window playing a video of a presenter speaking. When I record with BB Flashback, you can read the speaker's lips. Using CamStudio, the speaker appears to only be mouthing every second or third word.

    Similarly, if the video window displays a smooth motion (e.g. a ball bouncing), the capture from CamStudio is jerky, while BB Flashback is smooth.

    If I play the original video side-by-side with its capture, BB Flashback looks exactly the same as the original, while CamStudio looks choppy/jerky. That makes perfect sense since I can only get CamStudio to actually capture at 19 fps. If I crank BB Flashback's record rate down to 19 fps, the result is comparable to CamStudio.
  • Your results aren't surprising, assuming you're comparing a processed BB Flash video with a raw AVI created with Cam. The problem you describe with the Cam output is typical of videos with an unfriendly playback FPS. At the input rate you're experiencing, you'll get a lot of VOB repetition, which will lead to less than perfect motion, but the only way to confirm that is to do a frame by frame analysis in a video editor. Using Cam with Jawor's with packed bitstream and B-VOPs DEselected, you should get an effective capture of about 15 MS, but that's assuming you're getting a better input rate than you currently seem to be getting. I can tell you that, in the tests I did some time ago on our older Vista computer, the Cam results were clearly better than the BB Flash results.

    Ken
Sign In or Register to comment.