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.

Roadmap for future development?

edited November 2010 in General Discussion
Greetings all,

There has been some discussion lately about big changes on the horizon for CamStudio. Mostly, this has been in the form of assorted posts here in the forum. As a user of CamStudio, I am very excited about its potential, but I often wonder which changes will be implemented for certain (say, for 2.6 or 3.0), and which ones are more like "wishlist" items. A few examples: DirectShow, GDI+, alternative GUI framework (gtk+, qt), better AVI support, updated CS lossless codec, and a transition from C++ to C#. Some of these are already being worked on (e.g. DirectShow), and others are on hold (C++ to C#).

Is there currently a roadmap for future development? I've been searching for something concrete, but haven't found anything. I believe a roadmap written by the devs, with input from users, would be very beneficial to the project. It would provide focus for developers, generate interest from users, and improve everyone's overall perception of and belief in CamStudio. It might even help attract new developers, who may look at the roadmap and say, "Hey, I can code ! Sign me up!!" Ideally, IMHO, it would exist on a wiki, readily accessible from the camstudio.org home page. If something like this already exists, my apologies. I obviously didn't search well enough. ;-)

Additionally, I assume there must be some communication going on between the developers to keep things synchronized and flowing smoothly (?). Getting such discussion out in the open, e.g. on a traditional mailing list, would further improve focus and interest.

Just my opinions. Any thoughts? I understand there is a principle here that he who suggests the task, owns it. I'm not sure what I can do to help, but if I can, I will. :-)

Marc

Comments

  • I think that roadmap for Camstudio is nice too so that people can see what's the plan for the future...
  • This stuff is all being discussed now. Feel free to join developers' mailing list and contribute your ideas. I don't have much time as of now to invest. From what I understand C# version is dead-born and no one is working on it anymore. Last change was made more than a year ago. I don't even know what it can do and what it can't do.

    There are debates how to fix 2Gb avi limitation. I personally vote to choose DirectShow way as it will solve many problems at once, namely 2Gb limitation, support for bunch of codecs, audio & video can be muxed-in on-the-fly, and I also want to see a separate video stream for a webcam in the same container. As far as I understand, AVI container allows to do it, otherwise Matroska muxer is also available as DirectShow filter.

    As of GUI, I vote to move to alternative frameworks as it should allow to build the code with alternative compilers once we get rid of MFC. This, in turn, would allow to employ open source tools for code coverage and profiling. While these all is relevant for existing code, its cleanup, and bottleneck fixing for better fps; DirectShow introduction would require almost complete rewrite of the project, at least video & audio encoding, configuration options and their GUI etc. I personally can't work on it with Visual Studio Express. As a side-effect with toolkits like GTK+ or QT we will get good internationalization framework.

    Regarding GDI+, most of the code was written at the time when it was not available. Therefore stuff like anti-aliasing, alpha-blending and so on are not implemented as effectively as could be. It is not difficult to mix GDI+ code with GDI so it is not a big issue. AFAIK DirectDraw has even better performance, but it requires quite modern OS and won't work on Windows XP.

    Once again all this stuff is being discussed now. If you would like to contribute your thoughts or efforts, it is time! :-)
  • I'm not sure what might be wrong with CS codec. It works good for me. I saw some complains about outdated GZIP stuff, but by default it uses mini-LZO. While this can be updated, I'm not sure if it worth it. It has acceptable performance for capturing office stuff (not other video).

    In this area, one may contribute into improvements in ffdshow-tryouts as I feel like their CSCD decoder doesn't work properly with fast framerates (like if 200 fps were requested) http://ffdshow-tryout.sourceforge.net/phpBB2/viewtopic.php?t=1680&sid=94d5f69e25c0ee9ee3f0a13ead451aad .
  • To be honest, sometimes I'm thinking to move DirectShow tryouts branch to github as it provides more social coding rather than sourceforge infrastructure.
  • Thanks for the input, mlt. I'm glad to hear these things are being discussed. Though I'm not a coder (I've dabbled in C++ and a few other languages, but only scratched the surface), I would like to join the developers' mailing list. Where can I go to do that?

    Based on your description of what can be achieved with DirectShow, I must give a +1 for that idea. Sounds great.

    I can't agree more about switching to an open source GUI framework. So many doors would open up! Code profiling and i18n are extremely important. Additionally, a switch would greatly lower the barrier of entry for new developers due to reduced/non-existent costs, ease of use, etc. One can also consider the possibility of future cross-platform compatibility, if the backend code is modular in design.

    Regarding the CS codec, I've had no problems with it. I do tend to be a "bleeding-edge" software junkie, so the prospect of an update sounded cool. However, I agree; it works quite well right now. No need to break something that isn't broken. ;-)

    I also must agree with trying out github. Again, not being a coder, I've only interacted with the web-based frontend on a basic level, but in my experience github seems like a nice improvement over sourceforge.

    Thanks again for the input, and thanks to all the developers and admins who give their time to this project. Great work on the new features in 2.6b, mlt! Zoom is an important feature for me, so I was thrilled to see your demo videos.
  • Thanks for your feedback! I needed zoom feature badly as well so I had no other choice but to implement it.

    Perhaps, Nick can explain about mailing list. There is one on sourceforge, but someone had problems with it for some reasons, so there must be another one not that long time ago created somewhere here. AFAIK there were no activity on the new one so far. I personally see no reason in switching to it, but just fix problem with sf one. SF one is called "camstudio-devs". You should be able to see it once you are signed in, I guess.

    DirectShow though will eventually limit portability, but we have to choose.

    I was also impressed by github while I was providing a feedback on some R-project packages, one can even write comments on recent GIT transactions. That is really sweet and social :-)
  • Well, took a little searching, but I finally found the signup page for the mailing list. I'll try subscribing later when I have more time. Thanks for pointing me in the right direction.

    As far as portability, I would rather have an awesome Windows-only feature set and great performance than a multi-platform, "least common denominator" set of features. Just my 2 cents. :-)
  • About the GTK+ thing...
    If CS make a transition to GTK+, then this means that CS might work on Linux/OSX for the first time in history!
    About the portability...
    I don't think that adding direct show will reduce portability since most Windows came with direct show...
    Also if the project make a transition to C#, will this remove the C++ runtime requirement?
    About the direct draw/GDI+ stuff...I disagree using direct draw right now as the previous commenter said, it will break compatibility with WinXP. But I think sometime in the future we might have to use direct draw as nowadays programs are making transition to direct draw as the GDI+ are becoming outdated...
  • CS won't work on Linux at least because of GDI+ and DirectShow!!! While GDI+ can be substituted with Cairo, there is nothing to do with DirectShow. AFAIK wine implementation is not at the best stage if any. Also the capturing process itself uses bit transfer function specific to Windows (BitBlt).

    However, there was an idea to split GUI & command line. Thus it is possible to have somewhat similar GUI for both Windows & Linux, though Windows version would have a bunch of DirectShow filters' specifics.

    DirectShow stuff is a bunch of COM interfaces, which makes it natural to program in C++. While there are implementations even for Java, it all adds extra layers.

    I'm not sure what you mean by "removing C++ runtime requirement", and why you don't like those dlls.
  • edited November 2010
    If the C++ runtime requirements can't be remove, then perhaps make it installed automaticly while installing Camstudio?
    That's right that direct show is only for Windows. Direct show was bundled with Windows Media Player, and WMP isn't compatible with Linux.
    So to make CS work with Linux when we switch to GTK+, we have to create a build without direct show for Linux.
    Also I think to be able to port CS to OSX, we have to add quicktime movie support and we may have to make the program uses the finder menubar since all apps for OSX were forced to do that.
  • You can always download MS VC++ redistributable. I didn't ever had to. Perhaps only on pristine clean Windows installation. But if compiled with g++, libstdc++.dll should be included for sure.

    While DirectShow is not directly related to WMP, there is a work in progress http://wiki.winehq.org/DirectShow . Though it is not the way to go :-)

    "CS for linux" is called recordMyDesktop. I was thinking about splitting GUI & command line for CS to have uniform GUI and just swap command line tool, but I guess options set is quite different to even try to create uniform GUI. Though... somewhere in far far future. AFAIK recordMyDesktop doesn't support zoom. I didn't try it yet, but that is the impression I have from reading the web site. I wonder if stuff like shapes, different labels, and other overlay is extensively used by CS users? We definitely need some option so that users can opt-in to provide anonymous usage statistics like codecs used, options used, etc... But someone has to set up server to collect that stuff.

    QuickTime doesn't allow to have multiple video streams and there is no muxer for DirectShow anyway. I believe all menus go up top on OSX no matter what. I suspect even GTK+ ones. Haven't ever had a mac. And not going to.
  • @mlt Anonymous usage statistics would be quite valuable. Until that could be implemented, a simple poll might suffice. If a server is needed, I _might_ be able to get a shared hosting account. They're cheap these days. I definitely can't afford a dedicated server, however.

    Regarding overlays, I find them to be very useful. In fact, they can be invaluable for tutorials, esp. when targeting a novice audience. Other (related) ideas I've had that I would love to see in CS are desaturation of all but the active window/menu/dialog, a "glowing" highlight effect for buttons, and simple drawing tools with options to change pen width and color. I'm sure I can come up with other ideas in time. ;-)

    I used recordMyDesktop briefly in the past, and do not recall a zoom feature. In fact, I remember trying to use KDE4's built-in desktop zoom instead. I'll have to give it another go, because I can't remember how (un)successful I was.

    Since we're on the topic of a roadmap, I might as well throw another idea out there for consideration: preset and configurable zoom levels. For example, it could be useful to define a 320x240 zoom area to fit nicely into low-res youtube videos. Another idea that's been rolling around in my head (and I'm not sure how well it would work in practice) is a keyboard shortcut + mouse wheel zoom, for an "infinite" range of zoom levels with an intuitive interface. I understand how you are limited by VS Express, so these ideas can be projected into the future (post GTK+ transition, perhaps).
  • Zoom feature would be cool! I would like to be able to zoom into pand from fullscreen recording and zoom out from pand to fullscreen recording.
    Cos I've seen many vids on the net with that feature and I think it's really cool.
  • Well, thanks to mlt, basic zooming and panning is already finished. We just have to wait until the next build becomes available. :-) It really is a cool feature. For a screen recorder, it's a killer feature, IMO.
  • Thanks! Unfortunately I didn't touch panning code without zoom (so called autopaning) as I didn't need it. It can be still "quirky".

    @infinitech

    I actually thought that subtitles can substitute overlays... oh well.

    While desaturation for non active window area can be easily implemented, it would be somewhat cumbersome to do other effects for buttons etc. since CS doesn't have post-capture editing features. What button should glow? How can you choose one during the capture? These are just a few questions that are unclear to me at least now.

    I don't get about "320x240 zoom area"... if the movie's frame size is larger than that it will be scaled down in youtube anyway. And if it is proportional to 320x240 then it will be scaled nicely by itself.

    I was thinking about continuous zoom level feature, but I need to think how to implement smooth zoom. It is doable actually, I just thought that fixed level would be enough.

    @supanut

    What is "pand" ?
  • Panning is one of the feature built into CS.
    If zoom and pan could work together, it would be cool!
    Even if the feature will be exist in the next build but how can I zoom? Using the mouse scroll wheel?
  • mlt
    edited November 2010
    I don't understand the reason you may want panning and zooming if continuous zoom level will be implemented? It can be handled by zooming (and its panning) when you select to record whole screen or something. There are two kinds of panning right now in CS. One was before zoom feature. And another one provides panning while you zoomed in but limits you by original boundaries.

    mmm... that is tough to decide how to adjust zoom. I'd go with adjustable hotkeys as mouse doesn't have that many buttons to easily sacrifice. Like in IE/FireFox let's say Ctrl-+/-/0. Though mouse wheel with CTRL can also work. Unfortunately many programs already use virtually all possible combinations of ctrl/alt/shift and mouse wheel/button. Different GIS/CAD/photo and animation editing software are just few to mention.
  • edited November 2010
    Hmm, I hadn't thought of post-capture editing when I mentioned button effects. I saw a video once in which a button that needed to be pressed (e.g. a Next or Continue button) was highlighted with a color to make it stand out. Obviously, now that I think about it, that effect must have been added after the capture.

    Regarding subtitles vs overlays, subtitles are good, too.

    I'll try to explain what I mean by "320x240 zoom area". The effect of scaling is precisely what I wish to alleviate with zoom. When a video with a large frame size is scaled down in youtube, it is more difficult to read text and follow what is going on (for now, let's disregard the fact that one can simply switch to fullscreen and pick a higher resolution from youtube's list -- 320p, 480p, 720p -- in order to see the video clearly). For an extreme example, say I record a fullscreen video at 1280x1024 and post it on youtube. That video will be scaled down so much that it will be useless. However, if my capture program can zoom in on a 320x240 area, suddenly everything will be clear. I would stay zoomed in long enough for the viewer to read and absorb what is there, then zoom back out and continue on.

    You may be wondering why anyone would want to record fullscreen at a high resolution. Why not lower my screen resolution before I record, or capture only a small portion of the screen? Well, depending on what I'm trying to demonstrate in my video, a relatively high resolution may be necessary. Some programs become cramped, so to speak, in low resolutions. Additionally, fullscreen recording is necessary when the demonstration involves jumping around from the start menu, to an open window, to the tray, to an icon on the desktop, back to the open window, and so on. I say "necessary" loosely, because it is just my opinion. I may represent a small minority. ;-)

    Hopefully that is a little more clear.

    Smooth zoom adjustment is indeed tricky. Maybe another approach is necessary. Here's an idea borrowed from another screen recorder. Essentially, expand the concept of a fixed recording region to an adjustable region. While recording, the region would outline the area being recorded, and would have handles on the sides and corners to adjust its size. Dragging a corner in would result in a smooth "zoom" to the newly sized region (depending on how smoothly the user can move the mouse). There could even be a handle in the center of the region to move (i.e. pan) the entire region with a simple click and drag. The implementation details are beyond me, but this is a thought.

    Ok, too tired to think now. Sorry for writing a book, lol!
  • Right now if you drag corner (you might need a checkbox in fixed region setting), it is supposed to pan, but AFAIK it is also broken because of +-1 pixel bug.

    if you want your high resolution video to become sharp on 320x240 low resolution youtube, you'll need x4 zoom. In this case your source should be 1280x960 and not 1280x1024.
  • I can confirm that the fixed region setting is broken because of the pixel bug. Setting the dimensions of the region to 319x239 results in a playable video.

    Dragging the corner to pan works... but it could use some improvement. IMO, it should work like this: http://bit.ly/dslL4R (link to techsmith). In addition, I think the region size and position should update in real time. As it is now, dragging the corner results in a jump to a new location, rather than a smooth pan.

    You are absolutely correct about 4x zoom, and thanks for correcting me on the resolution (1280x960). Long ago, I remember using 1280x1024 on my old CRT. For some reason, that number stuck with me.

    I hope I'm not coming across as demanding or unappreciative. My intent is quite the opposite. I love the work that has been put into CS and have great respect for the developers who donate their time and energy. :-)

    Thanks!
  • Great discussion guys.

    Apologies for not being on the forum much lately, my workload just wouldn't allow it ...

    I'll post a sticky containing the link to the developer mailing list ...

    @infiniteh If anon stats are implemented, I have servers at my disposal to cover it, but thanks for the offer ...

    Cheers

    Nick :o)
Sign In or Register to comment.