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.

Please Read! Two Limitations of CamStudio -- Max File Size=2GB and Full-Motion Recordings

edited October 2012 in Announcements
CamStudio was originally intended for recording short screencasts of tutorial-style content, with the video having little motion, consisting mainly of program screens, with a microphone recording of a narration included if desired.

It always has been limited by its being written using the AVI 1 specification, which hampers us in that we are limited to a 2-gigabyte recorded file size. Over 2-gigabytes and CamStudio will crash without finishing combining the audio and video, and will leave un-keyed raw video behind that is corrupted.

Got that? There is a 2-GB file size limitation. You cannot go over that size, and there is no warning mechanism besides the filesize reading in the recording window -- and even that is approximate. I HAVE trusted it, though, and managed to record over 3 hours of webinar content using Jawor's Xvid at a quality=1 setting at 720p (1280X720), with MCI 16-bit, 44MHz PCM audio. However, webinar content has very little motion, and I recorded at capture frames every set to 100 and playback rate set to 10, with the set keyframes every setting at its maximum of 200 ms. This will look terrible for any full-motion video!

Full motion presents challenges. Though Xvid seems to work somewhat well, it apparently drops many frames, even when it is pushed with low numbers for the capture frames every setting and high playback rates (like 5/200). This is still being experimented with by others here, but any success you've had with CamStudio settings and codec settings in combination would be welcome news to post here. The issue is that attaining decent ACTUAL capture rates is a challenge on any but the most powerful machines. Even my 2.6GHz quad-core 64-bit machine does not do well in my experiments.

There are other limitations, but those are the two most glaring ones. Any comments or solutions are welcome!

Terry

Comments

  • I would hope that anyone who has done some work on advancing the process of capturing motion would post their results here. Judging by the responses to the Youtube tutorials and the base level problems people are reporting on this site, those who may have gone beyond getting the program "out of the box" are noticeably absent. This is where I am right now, for those who may wish to do some experimentation with configuration.

    Jawor's Xvid MPEG-4
    Key Frames - 200
    Mode - unrestricted
    Capture/Playback - 8/90 (converted to 125/30)
    B-VOP/packed bitstream - DE-selected
    Quality preset - Real Time

    Notes: I always convert to MPEG-2 with the GOP set at 12 (default) but there's little doubt that Cam's keyframes setting is interfering with the MPEG-4 process. Cam can pragmatically record using settings ranging between 5/1 to 5/6000, but as one approaches the lower numbers, the actual input rate gets very low and filesize (oddly) increases. B-VOP will cause frame flutter when combined with "real time", presumably due to mis-identification of I frames. Input is highest at 5/200, but this rarely produces the best result.

    Despite high VOB repetition, a capture made with these settings will be virtually identical to an original video BUT if the video source requires Adobe Flash Player to run, Cam's performance is significantly reduced. There may be some workaround for this, but I'm still researching.

    Ken
  • Well, time to update what I’ve been doing. I’ve now switched entirely to x264 and away from Xvid. I’m still working on the formulas, but there’s little doubt that this is a more usable codec.

    Honestly, my next question has to be whether there are any advantages in using 2.6 over 2.0. The older version is quite capable of “seeing” and using properly registered x264 and seems to be the most stable, user friendly version of the program. The fact that is very quirky when it comes to managing to “see” largely unusable codecs is more of curiosity than anything else, since we really have no need for those. No, it wasn’t designed to use Xvid or x264, but it works, at least when some adjustments are made.

    Any thoughts welcome.

    Ken
  • Ken,

    Now you've got me anxious to give x264 a try!

    I've been using 2.0 and 2.6c interchangeably lately. 2.0 is still a stable and reliable item, as long as you do not use "Record from Speakers"! ;-)

    Terry
  • I'm having a lot of trouble dealing with a corrupt video file that CamStudio produced. I got the same "rename / save" error as is being discussed in your post and the ensuing discussion here:
    http://camstudio.org/forum/discussion/350/known-bugs-and-limitations-from-wikibooks-article/p1

    I had followed the recommendations of a video I watched on how to (supposedly) avoid that corruption error - here:


    That video had recommended downloading and using "CamStudio Lossless Codec v1.5" with the following settings:
    Quality: 50
    Capture frames every: 25 ms
    Playback rate: 40 frames per second

    I recorded it exactly like that.

    I now have a 22 minute video that CamStudio saved as a 4 GB *WAV* file. Trying to follow the recommendation in the CamStudio.org post that I mentioned above, I downloaded VirtualDub and followed BookLover's directions. VirtualDub outputted a 62 frame video that plays for about 1 second.

    Do you have any idea what I might be doing wrong?

    I would very much appreciate any help or suggestions you could offer. This recording is very important and cannot be replaced...

    Thanks so much,
    Eliezer
  • Unfortunately, a 4GB file is much too large to save, and unless someone has come up with a magic formula for doing so (and isn’t telling us) there’s no way to salvage such a file. In my tests with lossless codecs, I found that I went over 2 GB in less than 5 minutes, and lowering the quality setting to 50 will simply eliminate any image quality advantage you might get by using a lossless, and the 40/25 setting will further degrade the final product. Bottom line is that the video you watched contains some very bad information.

    Terry: It’s a quick enough test. Just use the settings which vopo came up with in the thread below and you’re pretty much good to go. Keep in mind that it doesn’t seem to work at all with other settings. I’ve been using 5/200 and slowing the FPS to 30, which creates a most playable file.

    Ken
  • Eliezer,

    Like Ken said, that video had a lot of misinformation in it. Lossless codecs are for very special applications only, like archival materials, and are pretty unfriendly to us for other applications due to the very short record times. The longest I've gotten lossless was 9 minutes of 32-bit color video and 11 minutes of 16-bit color video.

    Terry
  • Ken and vopo,

    What kinds of maximum recording times are you getting from those settings? Is this viable to capture a gameplay video for the game recording enthusiasts out here?

    Terry
  • edited November 2012
    Terry,

    gameplay video needs high recording framerates. I haven't optimized this by now. My HD recordings all seem to be below 20 fps (real recording framerate, not the 40 fps nominal as shown by player).

    Max rec time is above 100 min for complex video (x264vfw, 1280x720) with 22kHz mono pcm audio. 44kHz stereo pcm is roundabout 7 mb/min more which makes 30% less recording time.

    Vopo
  • vopo,

    Awesome - thanks!

    Yes, even with the Playback Rate set, the actual capture is always lower. One has to push the Playback Rate setting higher to get the CPU to work harder - but that can slow down the program you are recording as source material.

    I'm going to play with this myself as soon as I get a chance and do some tests. Thanks for the input!

    Terry
  • edited December 2012
    There is kind of "fix" to double the 2 GB limit to nearly 4 GB.
    You need a software called "mplayer". In this software is a program called mencoder.

    The important step is: After stopping the recording (all records bigger than 2 GB and smaller than 4 GB) via camstudio, do not save (ignore the save-window and let it open) and copy the files ~temp.avi and ~temp.wav from c:\windows\temp to another directory. I recommend copying both files in the same directory where the mencoder.exe is.

    Then, you need the following code:
    mencoder -idx ~temp.avi -ovc copy -oac copy -o fixed-file.avi

    Create a batch-file with that code and start it.
    After a while, you have a complete new file called fixed-file.avi, which file-size differ from the original.
    Now you have to merge video and audio to one file and thats it.

    I've found the code in the internet, but i am not sure if it was in the camstudio-forum.

    But i really looking forward, that the 2 GB bug will be fixed.
  • That looks super-handy, perves! I'll give it a try on an over-sized test file.

    Terry
  • "Lossless codecs are for very special applications only, like archival materials, and are pretty unfriendly to us for other applications due to the very short record times. The longest I've gotten lossless was 9 minutes of 32-bit color video and 11 minutes of 16-bit color video."

    Are you confusing lossless with compression-less?

    Use ut video codec in RGB colorspace. I regularly make captures of webcasts at 10 fps which last more than an hour each. Key is to compress the audio.
  • I did mean "Lossless" as in "CamStudio Lossless" or "Lagarith Lossless", which are about the video capture.

    Do you compress the audio afterwards? My recordings always go out of sync unless I use MCI to record, or set it as PCM 16-bit 44MHz audio during capture.

    Terry
  • Terry, I think something is wrong with the notification feature on the site since I was never notified of your (or any subsequent) replies on this thread.

    In any case, regarding the 4.3 GB "wav" file that I do have... Is there any way at all to open / convert / salvage it? It is an irreplaceable recording...

    If anyone could please help, I'd greatly appreciate it.

    Thanks,
    Eliezer
  • Eliezer,

    You have to "bookmark" a thread to receive notifications. Click on the star icon to the right of the title to bookmark it. (That's how I saw you had posted just now!) :-)

    Did you try MediaCoder? They also have an audio-edition that is free: http://www.mediacoderhq.com/audio/

    Let me know if it salvages that file.

    Terry
  • Terry, thank you for the tip and the link.

    That looks like a big, fat, scary program. :-| Are you suggesting that the free version could help save the *video* of my file? :/ (Sorry... Confused...) Any idea (off the cuff) what I'd do with that program to save my video file?

    Thanks again,
    Eliezer
  • edited December 2012
    Eliezer,

    No, it would only extract the audio portion, which is what I thought you meant.

    There is no way in the universe to retrieve a video that has gone over 2GB that I know of (of course, it is a pretty big universe...) - so, do attempt to get the audio intact at the very least.

    I show how to record very long webinars in the 2012 tech webinar, so at least you will be ok for future recordings.

    http://camstudio.org/forum/discussion/980/2012-camstudio-2.0-and-2.6-b-c-tech-webinar-win7-xvid-audio-video-settings-etc-

    Terry
  • Actually, CamStudio left me two files - a "temp" WAV file (~230 MB) - that actually *is* the audio of the Skype call - and then the other "video / WAV" file (~4.3 GB). So I *do* have the audio already. (I guess I should be thankful for that!) It's the video I was hoping to recover...

    Like I mentioned up above:
    [ ... ] I downloaded VirtualDub and followed BookLover's directions. VirtualDub outputted a 62 frame video that plays for about 1 second. [ ... ]

    So there's *some* kind of video in that WAV file...
    Eliezer
  • Eliezer,

    The weirdest part is how the video was saved as a .wav file! That just floors me.

    I wonder if you changed the .wav to .avi whether MediaCoder could open it and rescue it? Or even AnyVideoConverter or VirtualDub?? (Never tried that... just speculating now.)

    That 4.3GB file still would be a challenge for any program to rescue, but I hope something will work on it.

    Terry
  • Eliezer,

    I looked at the thread, and it is an interesting discussion. Perhaps let them know that the 2GB limitation was imposed by CamStudio using the old AVI-1 specification (the AVI-2 spec has no such limitation). Please let me know if someone there finds a solution!!!

    Terry
  • Looks like we have lotsa different stuff in this thread.

    The issue of files being left behind as “.wav” has come up before. Apparently, the video file is the larger of the two and is therefore easily identified. What we start out with is a data file, which is processed into video stream. The fact that Cam attempts to process a data file without first doing a file check is a program glitch plain and simple. Data processed into a video stream will create a file much larger than the original data file was, so it’s safe to assume that what we have in this example is data which would produce a video much larger than the 4.3 GB if the video could indeed be processed. Doing a little quick math, the entire video file could be as large as 14 GB and the processed 2:52 portion would be something right around the 2 GB limit for processing. Had Cam been written to “lay off” such a file, what we’d have is a data file which might be processed using a different means, but what we have now is a file which contains a length of corrupted video stream and a lot of left over, unprocessed data.

    Let’s get to the lossless vs lossy compression conversation. The real question is how (and if) inter frame compression is used. In the case of the Ut video codec mentioned, the comparisons most often made are with Lagarith, and most everybody agrees that Ut wins hands down, but I have yet to run across anyone who goes so far as to say that it represents any kind of major breakthrough in terms of compression, and the latency advantages are largely overstated, in my opinion. Let’s keep in mind that this is not a new codec, and it’s had plenty of time to make some sort of name for itself, which it hasn’t done. In my own tests with Ut, I found it to have most of the disadvantages of Lagarith, although it would certainly be a good choice to replace Cam lossless, if it is felt that a lossless should be represented at all on the Cam download pages. I’d like to see some test results with codec setting specifics done at 480 or 720 (for example) to get a better idea of what’s the very best we can get from this codec.

    And that brings up what I believe is a most important issue concerning the results of tests mentioned in these threads. If we don’t know the specifics, the tests results mean very little. A 320 x 240 capture of one’s desktop is little more than a JPEG screen cap, and it’s really doing nothing to test the effectiveness of the program or the codec being used. I’ve used an 848 x 480 capture of motion video a standard for my tests, and vopo used a full screen motion capture for his recent x264 tests, and I believe those provide valid and useful test results. Anyway, it would be helpful if those posting test results would provide more information about what they did and how they did it.

    For the purposes of testing video codecs, the audio discussions are pointless, and it’s probably best to do tests with the audio disabled, just to get this issue out of the way. The real problem with audio capture is that the quality, no matter what type of compression is used, is just not as good as it would be if we were dealing with downloadable files. This is not a program issue, since we’re going to get basically the same results with the Cam audio as we will with Audacity, assuming we’re using the same hardware.

    As usual, any thoughts welcome.

    Ken
  • Bumping to the top...

    Terry
  • Hey Terry,
    Seeing your issue on 2GB limits have got me to find a ffdshow solution similar to your XVid solution. Mine involves using ffdshow tryouts revision 3572 2008 x86 with encoder H.264 with fourcc as H264 with mode of one pass - average bitrate of Bitrate of 900 kbps on 100 quality of camstudio. I know that the 2gb is still haunting the cam-studio recorder and this work around has to maintain a certain ratio to prevent slanting (using resizer with 640x480, 800x600, 1024x768, 1280x720 including the Windows "Bar menu" on Windowed region) but hopefully I'll find a better setting with a codec on my Win7-64 AMD FX-8350 Octa-core 4.0 GHz.
    Anyway, do you have any other tip on a workaround involving framerates, quality, and low size before you switch to AVI-2 Specification? I did a bit of recording with Camstudio 2.6c (Before all the fiasco with adverts/2.7.1) and I have a video uploaded with the settings and I would like to know how to improve the performance Framerate while maintaining quality with decent size.
    Thanks for reading
    ~Destroyer47
  • Destroyer47,

    Feel free to share any videos you make showing frame rates or otherwise. Just paste the YouTube link into the comment box here. It is good to know good settings to use with ffdshow!

    Rather than go through the bother with converting the file after the fact, try using the x.264vfw codec with CamStudio (That's the one being used by ffdshow anyway, I'm pretty sure).

    http://sourceforge.net/projects/x264vfw/

    Also, if you haven't already, watch my 40-minute tutorial on 2.7, and be sure to check out the links at the bottom in the "Show more" area for Sizer and ZoomIt among other things.

    Terry

Sign In or Register to comment.