Due to continual spamming, forum registrations are now by Invitation Only. Hopefully this will be only a temporary measure to combat spammers. If you want an invitation contact forumapplication @ camstudio . org Sorry for the inconvenience.
CamStudio 2.6 Beta released at Sourceforge
  • Only for the brave, of course! ;-)

    Seems to work fine!


    There is now a Camstudio 2.6 Beta support category here, through nothing is posted there yet as of this writing.

    Terry Britton
  • Hi Terry ...

    Steal my thunder will you ... ? ;o)

    Yes, this is the latest build of the 2.6beta (revision 264)

    It's pretty stable, but please only download and install it on a non-mission critical machine and make sure you install it into a different directory.

    C:\Program Files\CamStudio 2.6beta


    C:\Program Files\Camstudio

    Support for XNoteStopwatch and MotionControl systems have been added as well as some serious code refactoring.

    Next on the To-Do list is breaking the 2GB filesize limit by trying to implement OpenDML (AVI 2.0) format creation.

    Any support questions, please post them to the 2.6beta specific forum here:



    Nick :o)
  • Nick,

    Heh - sorry about that - I figured you got busy!

    One thing I noticed right away is that the read-out while recording in "Region==>Window" of the screen size is now OVER by one pixel in width and height, but the actual recording is what you'd set the window at. So, the one-pixel-added bug has been moved into the read-out screen, but has been fixed in the actual recording algorithms.

    That is, a 1280X720 pixel window is being displayed as being a 1281X721 pixel one. If it were actually that, using the Camstudio and other codecs I'd get that skewed horizontally picture in the recorded result.

    Oh... this belongs in the new forum category! - I'll go paste it into there!

    Terry Britton
  • Hi Terry

    Heh ... yeah you're right, I got swamped with other tasks ... never mind, so long as someone announces it, I don't mind :o)

    Thanks for the first bug report ... awesome.

    Keep it coming ...


    Nick :o)
  • Happy to see the project still up and running and the first blog post in two years :D

    Has 2.x updates been put ahead in priority then 3.0? Just curious.
  • wow, nice... thank you CamStudio
  • A few feedbacks:

    sometimes it hangs eating up 100% cpu. Pretty rare though, and killing it brings it back.

    Ihe first time I used it, I hit "record", selected a screen region, and then...nothing happened. Repeat, same effect.
    It seems to work fine now though so I'm not sure what the difference was.

    The "pause" and "stop" buttons stay visible (non-greyed-out) after hitting stop.

  • Just DL the latest 2.6b, installed it and ... fail:

    Whats wrong? :(
  • yamyam -

    That's in German - what does it say in English?

  • Hi Terry,

    it means:
    The application failed to start because the side-by-side configuration is invalid. For more information, see the application event log.

    Installation where fine and previous installed 2.0 worked fine too.
    I just cant start the new installed 2.6b :(
    In the meanwhile i de-installed 2.0 cause i thought it is maybe the old version which is making trouble, but cant start 2.6b even after 2.0 is gone.
  • yamyam,

    Well, I guess I still have a little ability of the German language, then. That's what I thought it said, but I just wanted to make sure! The "side-by-side configuration"... now that's mysterious!

    Is this Windows 7? I've never seen an error message like this one before! (Stayed-with-XP!)

    I've done a little research, and it is probably due to the DLL's being in the program folder rather than where Win7 expects to find them:

    "Now EXEs link with the DLLs found in the WinSxS folder in your System32 folder. "

    (ref: http://cboard.cprogramming.com/windows-programming/123653-side-side-configuration-incorrect.html )

    If that is the cause of your situation, probably one of these three (or all of them) need to be copied (or cut) from the Program Files/CamStudio 2.6b r264 folder & pasted into that WinSxS folder

    (...or the MS C++ runtime libraries installer should be run by the program installer ... which I've seen much occurring much more prominently since Win7 came out - that may be why!)

    mfc90.dll (mfcDLL shared library - retail version)
    msvcp90.dll (MS C++ Runtime Library)
    msvcr90.dll (MC C Runtime Library)

    These are in the Program Files/CamStudio 2.6b r264 folder now. Try copying them into the Windows/System32/WinSxS folder in your Win7 machine. If copying still doesn't work, move the ones out of the Program Files/CamStudio 2.6b r264 entirely (to your desktop, for temp keeping) and then test it.

    OR go to Microsoft and download and run the MS C++ Runtime Library installer package:

    (or in German: http://www.microsoft.com/downloads/details.aspx?familyid=A5C84275-3B97-4AB7-A40D-3802B2AF5FC2&displaylang=de ) ;-)

    or from


    Let me know if that works!

  • Hi Terry!

    No, never used win7 till yet - it is vista!

    And i never ever had any problem with 2.0 before.
    I just de-installed 2.0 and installed the current 2.6b.

    2.0 worked fine.
    2.6b i cant even start as this error occurs, which i also never seen before.
  • Never heard before of this but certainly requires a little study.


    Would be nice if we could run test before on systems with different OS and language installs.
    Another possible solution to prevent this side-by-side errors could be to link the Dll's statical instead of dynamical. (Although I don't like that it shall work)

    Other links (less important):
  • This looks promising ...

    Create projects easily with private MFC, ATL and CRT assemblies
  • And how does all this helps me to get camstudio started?
    Or please name me alternative software pls. thx!
  • yamyam,

    Go to Microsoft and download and run the MS C++ Runtime Library installer package:

    (or in German: http://www.microsoft.com/downloads/details.aspx?familyid=A5C84275-3B97-4AB7-A40D-3802B2AF5FC2&displaylang=de ) ;-)

    Restart your computer and the Camstudio beta should work. If not, just re-install and use 2.0 for now. It is pretty stable, and you already know it works.

  • @yamyam

    Terry is right, it's an issue with MS C++ Runtime DLLs

    Follow his instructions. If 2.6 doesn't work, revert to 2.0 until we can get it fixed.


    Nick :o)
  • About Side-by-side issue:

    A fighting dll approach as proposed by Terry can work but it is not a persistent solution. Other users may suffer same problems and will ask for help.

    I'm busy to introduce private assemblies for release mode (solution advised by MS).
    In that case application.manifest file define which dll's will be used.
    In our case, the dll's that comes with our distribution and we used for testing before.
    I expect that this will solve the side-by-side issues.

    Need people who tried to install/use Camstudio but failed due to side-by-side to verify that it works before we release this as a new revision.
    @Volunteers , send a message to me.

  • Thanks ... its working now! :)
  • yamyam,

    Yipeee!!!!!!!!! :-)

    I suppose that what Janhgm is adding to the next release will resolve this problem for future installations, so you've helped a great deal by pin-pointing what the problem was. I hope the rest of your experience goes smoothly! (Ahhh, there are always more things to learn, of course!)

  • Windows 7 x64 doesn't have a WinSxS folder but still gets the error. Moving the three dlls out of the program files folder does not help of course.

    The only winsxs Windows 7 x64 has is full of registered and hashed resources: http://imgur.com/PfJj1.png

    Seeing as I was able to use 2.0 with the 2.5 beta overwrite... I don't see why I shouldn't be able to use this.

    I can't copy the three DLLs to that folder even as CMD.exe administrator.
  • coldreactive.

    Try installing the C++ libraries for x64

    64-bit http://www.microsoft.com/downloads/details.aspx?familyid=BA9257CA-337F-4B40-8C14-157CFDFFEE4E&displaylang=en

    Restart your computer and the Camstudio beta should work.

    I don't know whether, if running 32-bit applications, you would also need the 32-bit libraries installed, but you could try it if the above doesn't help.

    32-bit http://www.microsoft.com/downloads/details.aspx?familyid=A5C84275-3B97-4AB7-A40D-3802B2AF5FC2&displaylang=en

    Let me know if that works for you.

  • Need someone who still get side-by-side configuration errors for a test.
    Would like to know if you can start recorder.exe if this manifest file is available in the same directory as your recorder.exe.

    Create empty file with name:

    Copy XML below to file and save:

    Double click recorder.exe
    Does it start?
  • Seems like installing the C++ stuff made it now open. But now I have another problem.

    CamStudio will NOT record at all with the ffdshow codec using xVid 3 and ffds together with one-pass quality. It'll just spaz out, and causes the CamStudio dialog not to redraw, and hang while recording. No information will be updated on the dialog, everything at 0 except the 32-bit color information.

    Pressing stop causes CamStudio not to do any "Compressing Audio" on the title of the dialog, and seeing as I had no audio anyway playing, you'd think it'd save the video, without telling me it did; it didn't however. I had to close CamStudio, not knowing if the video had saved, I could press buttons, etc. so it wasn't hanging in the API. When I closed it, Windows gave the fancy crash dialog asking if the program quit correctly, etc.

    Any reason why it's doing this?

    it's on the Youtube 480p for fixed region size (no fixed top-left)

    My computer is an AMD Hex-Core with an ATI Radeon HD 5750. I have 8 GB of RAM as well. Hex-Core is 2.6 GHz.
  • Actually, all codecs seem to be causing the api to freeze up like this.
  • I tried Janhgm's file but it didn't change anything so i installed the libraries:
    the 64bit didn't work either so I installed the 32bit C++ libraries and i can open it now.

    Now i get the same problem as coldReactive: after clicking the stop button nothing happens (in all of the modes) except that it says at the status bar "ready", but when I close the program I do not get any error messages.

    I have ATI Mobility Radeon HD 5730: VRAM 1GB; Win7 64bit with a memory of 4GB
  • ColdReactive and shrear,

    This is super odd behavior - I can only offer guesses and suggestions for things to test, as I do not use Win7, let alone Win7 64-bit.

    First, check in the place where CamStudio is storing its temp files to see if the files are actually still sitting there. This will be in the folder selected via Options==>Program Options==>Directory for Recording. The options there are:
    Use Windows Temporary Directory
    Use Application Installed Directory
    Use User-Specified Directory

    Make certain that the drive with this directory has tons of space available to it, as this is where the raw video and audio will be stored before being processed with the audio and video being combined.

    If you do have temp files still sitting in there, they will be in the format
    1. ~tempXXX.avi (e.g ~temp001.avi)
    2. ~tempXXX.wav (e.g ~temp001.wav)

    The files may be corrupted. If so, you may want to try repairing them with a third party AVI editor like VirtualDub

    Also check to see that this is set: Options > Program Options > Name of AVI file > Ask for file name
    If this was set to "Automatic File Naming" look for a finished video whose name is a timestamp.avi in your program directory.

    Any luck???

  • Sort of...
    If using the default option "use application installed directory" there exists definitely no file in my whole Laptop which could be it.
    If using the option "use Windows temporary directory" or If using the option "use user specified directory"
    there are two possibilities: when toggled recording Avi there is when pressing stop an error called "Note"
    "File Move Error. Unable to move or to rename/copy file. The source file may be opened by another application or destination file stilll exist.(still is written there with three l)
    Please use another filename."
    The temporary file exists and as soon you copy pasted it in some other location you can open them. But you can't close the Error message nor CamStudio other than by using Task-manager. The temporary file exists and as soon you copy pasted it in some other location you can open the file.
    when toggled recording Swf there is no problem...
    ...for the Avi fille but a)the program crashes and B) the Swf file created has 0KB size...
  • Same for me - I can only offer guesses and suggestions for things to test, as I do not use Win7, let alone Win7 64-bit. -

    But since v2.6b ~temp.avi files no longer exists.
    Each initial recording gets CCYYMMDD_HHMM_SS in it's name. That is for sure..!
    I believe leading token for temp files is still "~"
  • Is it normal that there is a huge number of page faults during recording? There is also growing number of GDI objects that causes camstudio to crash. I proposed solution for this on sf.net tracker.
  • @mlt;

    Thanks for your patch. It is applied as prt of r271
    If you see other things to patch just shout.

  • Maybe I'm missing it, but Sourceforge is showing the latest build as "CamStudio_2.6b_r264_build_14july2010.exe" and not r271. Where do I get r271?
  • @ jrothra

    Not all changes in Sourceforge results in a binary available for everyone. To much work involved with that. We assume that people who are interrested in development are able to build their own executable from the sources.
    Newer binaries can be found occasionly on my own website

    But v2.6b-r273 can be downloaded from Sourceforge now.

  • New version/release available for download.

    Camstudio version 2.6b release 273 is released on Sourceforge.

    Will be available on Camstudio.org soon.
  • I guess I can use this forum to propose an improvement.

    Right now, mouse capture is used to catch all mouse events as it is in TransparentWnd.cpp of Recorder. This unfortunately doesn't always capture all mouse clicks:(
    I propose to use hooks to capture mouse events. It seems should be possible to install handler to catch all mouse event before they reach window procedure of any window. This will allow to capture all mouse clicks with confidence.
  • Hi mlt,

    Improvements are always welcome. :-)
    I know you can code. Do you have an opportunity to write the patch and to put it in SourceForge?

  • Well, I might do it:-) I just posted it to secure everyone's consent so I understand current implementation correctly and I don't propose to do something nobody wants or that is already planned/being implemented somewhere in a branch.
  • No problem.

    Any improvement is welcome. If you want to be sure that ir will not break on different OS's you can create a private version first and use the forum to ask people to test it.
    As far as I' know, Terry is involved with setting up a new test team.

  • I uploaded drops26 branch with preliminary code that tracks all the clicks and shows them as growing circles. It is not perfect though, but you can get an idea. It is an alternative implementation of part of InsertHighlight for mouse clicks. The corresponding option should be enabled in cursor settings. I added WH_MOUSE_LL hook to track buttons.

    Btw...Why do we use GDI and not GDI+ ? It would be nice to use anti-aliasing and transparency.
  • @mlt

    Thanks for the code upload.

    I'm sure Jan will be able to answer the GDI/GDI+ question (cos I definitely can't ;o)


    Nick :o)
  • I made some cleanups. Now all mouse buttons are shown in different colors, up & down events are shown differently, mouse wheel is visualized.
    I propose to merge back into the main tree.
    Can someone add yet another dialog option for middle button color since you are moving to new profile or something. I don't want to mess up with settings and RGB works fine for me. Green is currently hard coded for middle button.
    Can something be done with BitBlt to improve appearance of highlights on dark backgrounds? Something like merge, but with color preservation.
  • Okay! GDI+ and transparency is used for mouse highlighting in drops26 branch. Please test!
    Anyway, now I feel like I can record what I was planning to do instead of coding :-)
    I hope you don't mind against small assembler code in the project for efficient conversion of COLORREF to ARGB with transparency :-) It required 80486+ processor. I hope I didn't brake anything else.
  • Here is the video if you don't want to build source code http://www.vimeo.com/15856221
  • @mlt

    As Camstudio started many years ago and new development is not really planned there is a lot of legacy in he code.
    Using GDI is one of this. Using VFW that gives troubles with the 2 GB file size is another.

    I just looked to your code. Excellent that you also write some comments what you want to achieve.
    Would like to ask to use variable that are a little more readable by making them a little more self-explainable.
  • I'm just curious what is actually wrong with VFW? The capture should be way longer than half an hour to hit 2GB limit. I had recording for 15 minutes with audio and it was ~600 Mb with 1280x720. Do many users have a need to record hours of video? AFAIK virtualdub has support for AVI2 format. I'm just curious if it would be possible to borrow code, I guess both are GPL. I am not positive that writing a support for AVI2 from scratch would be easier.

    I will cleanup code a bit, I just wanted to get it to work ASAP. I'd like to have zoom feature that I may add soon.
  • Code re-use
    Everything we can borrow from other project is better than starting from scratch.
    If we borrow code we should think before how we shall implement it. I prefer use of libs above code because libs allows us to follow ongoing development mush easier.

    I assume that the performance penalty was the reason why GDI was used instead of GDI+. As most systems are much more powerful now than a few years ago I do not see any objection to use GDI+.

    Inline assembly
    Dislike the use of inline assembly because we do not know how well this will work with other and future OS's. With inline assembly we neither have possibility to implement fail-safe solutions.

    VFW vs DirectShow ( AVI2 / Aforge )
    People are indeed running long full screen sessions with Camstudio (Movies from TV for instance)
    Also the possibility from Camstudio to record in high fps rates will make that 2GB is often a burden. (Although this is also because the AVI container is defined in 1988 and 2Gb was enormous amount of storage at that time)

    One could say that VFW and old style AVI containes as implemented with VFW are classified as effectively obsolete for many years. To my best knowledge many new development is using DirectShow now. There are a lot of things you can do with DirectShow that you can't do with VFW.
    If you have a look to this just look to Aforge. Use of Aforge can improve many things in the near future.

    Zoom feature
    Excellent, but we need to be sure that this new features works on different OS's.
    I assume that you will add an user interface to let users decide to use these new options.?
  • Inline assembly
    I doubt that 80486 instruction set will be changed in the near future. Unless we use exotic processor and non x86 architecture, we should be good. That chunk shouldn't depend on Windows OS version, but it does depend on default calling convention, which can be specified explicitly.

    VFW vs DirectShow ( AVI2 / Aforge )
    Capturing a movie sounds like a task indeed. However AFAIK there should be some software that comes with capturing board. Anyway, I was just curious.

    Zoom feature
    My current plan is to add CRect _zoomFrame that would hold current viewport within viewFrame boundaries. If autopanning is enabled (for viewFrame) and zoom> 1, it will adjust _zoomFrame instead, otherwise zoom is done at once to current mouse pointer location if autopanning is disabled (for viewFrame). Thus I plan to reuse some existing settings. I plan to make zoom smooth. For this I'm going to use Graphics::DrawImage from GDI+ which is known for bad performance. At least for me, it works fine and provides non-aliased magnification, as it is too much pain to use StretchDIBits in my opinion.

    Bad news is that I have VS Express (don't ask me how I compile :-) ) and I cannot edit any dialog as resource editor is not available. I was shocked recently about current inflexible implementation of keyboard shortcuts. For now (my purposes) I'll hard code it to F12 or something. Mouse highlighting is an alternative implementation, so I guess it is not reasonable to let user decide since original highlighter is not good at all IMHO.
  • r281 @ drops26 branch has somewhat working zoom feature. I tested it only with fixed rectangle. Zoom is hardcoded to F11. Video showing new features should appear soon http://vimeo.com/15885532 .
  • Cool.
    Great to see that the project is still alive.
    Hope final version soon!
  • Just to let everyone know, I'm working on libconfig ( http://www.hyperrealm.com/libconfig/ )integration. It looks very promising. This would allow to store setting in hierarchical format. I'm trying to make as little changes to existing code as possible. I'll upload it as a yet another branch, perhaps libconfig26.
  • In theory it should be possible to store all annotations in separate text (not binary!!) configs and just include them in the main one. Here is how piece of config may look alike:

    XNote = {//;[XNote];
    DisplayFormatString="(0000) 00:00:00.000";

    TextAttributes = {
    text="(0000) 00:00:00.000";

    font = {

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion