I have to say that your experience differs from mine completely. First, I’m curious as to whether your access to Xvid is through Jawor’s in all cases. The waveout error shouldn’t be happening in Xvid, if it’s not happening with x264, assuming your capture area parameters are being set correctly, and your stereo mix is enabled, which we know it is, since Cam is able to record audio in most cases.

Again, in my own experimentation with 264, I’ve found that one has to throw so much bitrate at the process to get it to achieve comparable quality, that the file size actually winds up being larger. Also, the image and motion stability which you’re experiencing with Xvid shouldn’t be happening. This MAY be caused by the fact that your FPS is out of range for most media players and that they have an easier time dealing with the 264 version, assuming both are in a comparable AVI container.

The standard Xvid interface (on which Jawor’s is pasted) enables B-VOP by default. That MAY cause problems if you have the recording mode set to real time. I’ve disabled both packed bitstream and B-VOPs in Jawor’s and have seen no instance of flutter whatsoever.

Getting back to your first post, the audio misalignment problem is puzzling and should never be happening, assuming that there is no audio compression used and other settings are correct. I’ve never been able to simulate any audio offset using any sort of audio with any video compressor, including some of the very obscure ones which I’ve tried. Lag is another problem, since it can be caused by a difference between the I/O bitrate in a compressed format such as MP3, but I don’t think that this can occur using CamStudio. (I may be wrong about that).

Your files seem to be within the 2GB limit, so I wouldn’t be concerned about the size of the audio file at this point. It would be easier to go with the uncompressed audio and split the webinar in two pieces, if it turns out that you have one which is so long that the audio file builds up to a size which might take you over the limit. (and even Terry can’t talk that long).

While I can’t say that I’ve completely excluded the notion of trying x264 entirely, I can tell you that I’ve been disappointed with the results so far.

BTW I’m understanding the German version a little better than the English one, so I’m responding here.

The video you chose for your test is a very good one, and the x264 has done a great job in capturing the motion. I’d certainly stick with that and deal with the audio as a processing issue rather than during the capture process. I don’t like lame MP3, but if you need to use it, I’d convert after getting the recording made.

Your Xvid sample is showing severe negative effects of packed bitstream, and in fact, it’s the best example I’ve ever seen as to why packed bitstream needs to be disabled in CamStudio. That’s what’s causing the bad motion. The “back” frames are actually being repeated, which causes the apparent halting in the motion. To do a fair comparison, set Xvid to unrestricted mode and disable both packed bitstream and B-VOPs and run in “real time”. You probably won’t get any better than you’re getting with 264, but it’s a better test. Move to target bitrate on the Xvid interface and set to 6400.

Anyway, your x264 sample is a great example of what can be done capturing HTML5 video. Now if we can figure out how to get the same quality with video driven by Macromedia Flash, we’ll have the whole thing working perfectly.

Yes, that’s better, but there’s no question that the motion of the x264 version is smoother. I’m going to do some tests using 264 in the next few days and I’ll post the links to my results.

I seem to be getting much higher input rates than anyone else here, and now I really don’t know why that is, but I generally get about 45 FPS on large videos and something close to 100 on smaller ones. I have only 4 GB of RAM, so that’s not the answer.

I don’t have much problem with Flash, except when I use it with CamStudio. It’s using too much resource and causing Cam’s performance to suffer. The Youtube sample video that you captured does not use Flash, so I have no problem with it. Many videos and games use Flash, and they just don’t work as well for me using CamStudio. A lot of people have been complaining that the recent versions have been using too much resource, and the Adobe people finally admitted that they had a problem and released a new version which is less resource intensive. I tried it and found that it is a little better, but not much. I then read that Firefox was recommending version 10.3.183.25 which is quite old, but, as it turns out, works much better than the newer ones. One might have thought that, after Steve Jobs essentially fired Adobe for not producing software that works in today’s world, they might have made improvements, but that doesn’t seem to be the case.

I’ve now done some tests using the same Youtube video you used with the same x264 settings, and I’m getting the same result. I’ve also run it through a video editor and slowed it down to 30 FPS which works very well also.

All I can tell you about the “actual input rate” is that when it falls below 40 I notice that it begins to cause problems. The only time this happens on my computer is when the Flash player is running at the same time that CamStudio is. My highest input rate is with x264 set at 5/200. Perhaps someone knows why my input rates are so high, but I don’t.

I tried lowering the color from 32 to 16, but I did not like the result.

One interesting thing about your test video is that you managed to get a pretty good result with Xvid, and 264 using a 25/40 setting. That should not work as well as it is with either compression method. I’m going to try some tests using x264 with some of the settings I’ve been using on Xvid, and I’ll upload a sample if I have any success.

Here’s a look at the video with different settings. This was done at 5/200 and slowed down to 30 FPS. It’s a formatted MPEG DVD, so you need to view it at full screen. I used way more bitrate than I needed, resulting in a rather large file.

As for me, audio is always recorded in PCM format, no matter what format I set, I have only the option to compress the audio later if I want to get the smallest file sizes. For future audio compression e.g. with Virtualdub/mp3 definitely CBR (not ABR), else unsynchroner sound! CBR is available for 32kHz or 44kHz, so either convert later sampling rate equal to or record properly with 44kHz (larger file> 2GB limit!)

A test recording of a 91 minute webinar provided (with video) format 862x644 before the audio compression size of 544 MB, ie 5h recording without exceeding the 2GB limit should be in there. Audio and video portions of the file were about the same.

I plan to make another test with 720p so standard 1280x720 resolution. File size achieved after I submit it.

The comparison with the x264 Xvid codecs in terms of quality vs. File size is not yet succeeded me as Camstudio when selecting the Xvid codec to record with the error message "Wave in error: The specified device handle is invalid in Stop ()." Does not even begin.--------------------------------------------------- I managed to compare x264 and Xvid now. Xvid works for me only if I as a "region", "Window" adjusting and then only in some window sizes.

Default in Xvid is yes: Profiles Xvid Home, Target quantizer fourth During my test I reach for x264 with preset UltraFast, rate control CRF30 similar file sizes. Quality is still okay.

Profiles Home Xvid or Xvid HD 720 did not make a significant difference, So I stayed for the 2nd Test with standard Xvid Home:

Profiles Xvid Home, Target quantizer first These are the best quality. File is 2.4 times as large as before. X264 setting preset UltraFast, rate control CRF23 (CRF23 is standard) increases the file only 1.6 times at least the same quality as Xvid, if not better.

Remains to mention that the picture to the audio in XVid lags a bit less, so instead of just 500ms 400ms delay is set. If sound, long takes remains synchronous imaging I have not tested for Xvid.

With the above information the audio portion of the file size is not removed. I therefore here again the proportion of pure video (the audio portion was always 1.30 MB):

All in all, I feel in the assumption confirmed that'll prove himself against x264 Xvid as the more efficient codec. Because on my computer and the time delay is not in Xvid disappears, I will encode in the future with x264vfw.

The fps is not. I go down to Xvid at 20 fps, it gets worse. By Camstudio specified when recording "input rate" is constant at x264 at 13.6 fps, in Xvid only at 11.3 and drops while recording continues on from below 10.

B-VOPs off significantly improved the quality of Xvid. There is no image more jumps. "Real-time" mode causes minimal improvement over "General purpose".

The image lag compared to the soundtrack, I can confirm for x264 only once. But can be well compensated by the delay.

All in all the x264 version is still much better.

As for the lack of audio compression: I find it somewhat unbalanced, edit the video portion with the latest craze in video compression, the audio portion but to leave uncompressed, although yet to even with the relatively old and very little CPU time requiring lame mp3 audio part 80 % compared to 22kHz mono PCM (44kHz PCM stereo still significantly more) can be reduced in size.

All in all I am because of the expense of Camstudio need to be operated to adjust, not exactly enthusiastic. The necessary adjustment differences that arise from apparently divergent Hard-/Software the user give the program the feeling of a Diva.

Perhaps it’s easily missed in this very long exchange, but it might be noted that both of us are using a key frames setting of 200. In my analysis of both x264 and MPEG-4 finished videos, I’ve come to the conclusion that anything else interferes with the codec’s ability to properly set key frames, and in fact, I’m wondering if 200 isn’t just the least of all possible evils. Normally key frame intervals for MPEG-4 is between 300 and 700, so we need to be asking why Cam is operating entirely out of that range. Note that Cam will NOT run with key frames set at 0, so the program is definitely trying to impose some sort of key frame limitation. I’m wondering if the new version will address this issue.

Ken, there's no specific reason why keyframe rate settings originally of 30 and lately 100 are selected other than people have posted on the forum and emailed me with settings they've gotten good results with and so after testing them ourselves, we go with them.

I never knew that normal keyframe rates for MPEG-4 are between 300 and 700 frames so I did a little digging and found a similar figure on the SorensonMedia forum.

Scrolling down to the keyframes section of the page it mentions a figure of 300 as well as a couple of extra pieces of info I also didn't know about increasing/decreasing keyframe rates depending on the amount of movement or change on screen during recording.

A figure of 300 (and maybe more?) may well work well for screencapturing with CamStudio where there isn't a lot of movement on screen which would also help to keep the final filesize down and is definitely worth testing.

In 2.7, when AutoAdjust is selected (as default now) the keyframe rate can be edited separately so users can fine tune the settings better.

@TerryBritton - maybe it's worth doing some test recordings with a key frame rate of 300 using x264 and Xvid to see what type of results we get?

Actually, I was under the impression that the highest setting we could type in there was 200! I'll see if I can get 300 to work, and measure the difference with a same-length recording of the same content.