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.

Discontinue CamCodec?

edited November 2009 in Code Contributions
I was looking through the code for camcodec today as I tried to add it to the new installer package. CamCodec just uses an outdated version of zlib to perform HUFFYUV like compression. There are more recent versions of zlib that provide performance, bug and security updates. There are also other open source lossless codecs that have been updated int he last decade and have other developers currently maintaining them.

The only reason I see to continue supporting camcodec is that it guarantees that our users have a lossless codec installed on their system. If we included another open source (or maybe even freeware) codec in our installation it would be one less thing for our tiny / non-existent development team to maintain.

I've only done some research but, Lagarith ( seems like a decent choice if we do replace camcodec.

Anybody have any other complaints about discontinuing CamCodec in future releases or suggestions for a lossless codec that could replace it?


  • edited November 2009
    I agree Lagarith is a good option, I have yet to find a codec (other then CamStudio Lossless) that can match Lagarith when you factor in encoding speed and compression. If you enable "Null Frames", Lagarith definitely outperforms CamStudio Lossless in compression (at least on LZO, I've never gotten CamStudio's GZIP setting to work), I'm not sure about speed. Although "Null Frames" might not be what you want if you plan on doing a lot of editing and without the option enabled, CamStudio Lossless can actually produce smaller file sizes then Lagarith in certain situations.

    I don't see any reason to completely discontinue CamStudio Lossless though, it wouldn't necessarily have to be included with CamStudio. From what you say it might be more trouble then it's worth to update it beyond bug fixes, but one nice thing about the CamStudio codec is it's been made (at least partially) cross-platform and can be uploaded directly to YouTube and other sites (if you use the right settings). Does it really use a HuffYUV like encoding scheme though? It's compression ratio is many times better then anything I've ever gotten with Huffy (at least for screencasts).

    Lagarith, on the other hand, is completely limited to Windows. While it is open source and has been out for years, I don't believe anyone's tried to port it and it doesn't work with VLC, Blender, and the like. It also doesn't accept CamStudio's keyframe and quality settings, although it might be possible to change CamStudio's code so it does.

    I don't know of any other good alternatives besides Lagarith though. I've read good things about Ut Lossless (, but I don't believe it's up to par with Lagarith when it comes to compression. As for the others I've tried, they create much larger file sizes (HuffyYUV), require a lot more processing power to encode (FFV1), or could create licensing issues (MSU).

    EDIT: reworded (again)
  • edited November 2009
    Thanks for the input, it seems like you really know your stuff. I didn't know that Lagarith wasn't compatible with VLC and the lot so it might not be as good of an option as I originally thought. By discontinue I just meant to stop including it as the default codec in CamStudio. Overall there seem to be the fewest bugs in the codec so maybe its worth it to keep the compatibility. Nick mentioned that he liked ffdshow, especially since it can encode to .flv and h.264. I still need to look into them some more before I have an opinion.

    Do you know anything about the differences between Video for Windows and DirectShow? Again, I've done some research but I'm not sure what the best direction for camstudio is. I think camstudio needs some serious refactoring and bug fixes, but if its based on an outdated standard should the backend just be rewritten? If it is rewritten to use DirectShow, then I think it will be compatible with more codecs and containers and not have the audio / video sync issues we sometimes see. I'm a programmer who doesn't have that much experience with video. So, I'm trying to make sure I understand the domain better before I jump in and start coding something that's not really going to solve the problem.
  • edited November 2009
    It's not so much that Lagarith is incompatible with VLC itself, but the libavcodec library ( that VLC uses. While the libavcodec does support the CamStudio Codec, it's only at certain resolutions (I think everything up to 800 by 600, I know HD resolutions aren't supported), it's better than nothing though. I'm not entirely sure why Libavcodec doesn't support Lagarith, but does support CamStudio, my guess is based on what you mentioned, that since the CamStudio codec uses a much simpler method of encoding it was rather trivial to implement.

    Backwards compatibility might be another issue considering the CamStudio codec has been around for awhile and a lot of material has already been encoded with it.

    Personally, I've had more luck with Lagarith then with CamStudio LossLess. This is probably because I mostly have used VirtualDub for my editing and Lagarith was written specifically with VfW and VirtualDub in mind.

    I don't know much about the differences between Video for Windows and DirectShow. I know that Microsoft discontinued Video for Windows a while ago, but still maintains the code for backwards compatibility (it was included with Windows 7 and Windows Vista). DirectShow, from what I've read, sounds quite difficult to work worth, much more so than Video for Windows, and I've read that Microsoft is in the process of discontinuing directshow as well, in favor of "Media Foundation". The problem with "Media Foundation" is it's only available for Windows Vista and Windows 7. I'm not really sure what the answer is here, the doom9 forums, stackoverflow, or devshed would be a better place for this kind of question. I know CamStudio has been discussed on doom9 in the past, it might be a good place to start:
  • Still applicable:

    CamCodec just uses an outdated version of zlib to perform HUFFYUV like compression. There are more recent versions of zlib that provide performance, bug and security updates. There are also other open source lossless codecs that have been updated int he last decade and have other developers currently maintaining them.
  • Will zlib update affect other applications that rely on camstudio codec like ffmpeg. If ffmpeg compatibility won't brake with newer zlib, I'm voting for updating it.
Sign In or Register to comment.