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.
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.
German: Einstellungen für hohe Qualität und kleine Dateigrößen
Man benötigt 2 Dateien:
CamStudio 2.6c_r303 http://sourceforge.net/projects/camstudio/files/next/Camstudio-2.6c.7z/download
x264vfw Codec http://sourceforge.net/projects/x264vfw/files/x264vfw/37_2200bm_33968/x264vfw_37_2200bm_33968.exe/download
Folgende Einstellungen funktionieren bei mir (Windows 7, DualCore Prozessor) sehr gut:
Video: x264vfw, Q100, key200, frame25, 40
x264vfw config: ultrafast, CRF23, Loglevel=none
Audio: 22kHz, mono, 16bit, PCM(nicht änderbar!), Interleave1000ms, kein MCI!
Audio and Video Sync.: 500ms delay (die aufwendige Videokompression führte sonst zu zeitverschobenem Ton!)
Da bei mir Audio immer im PCM Format aufgenommen wird, egal welches Format ich einstelle, bleibt mir nur die Möglichkeit, den Ton nachträglich zu komprimieren, wenn ich kleinste Dateigrößen erreichen will.
Für spätere Audio Kompression z.B. mit Virtualdub/mp3 auf jeden Fall CBR (nicht ABR) benutzen, sonst unsynchroner Ton! CBR ist nur für 32kHz oder 44kHz verfügbar, also entweder später Samplingrate konvertieren oder gleich richtig mit 44kHz aufnehmen (größere Datei-> 2GB Grenze!)
Eine Testaufzeichnung eines 91 minütigen Webinars (mit Video) im Format 862x644 erbrachte vor der Audiokompression eine Größe von 544 MB, d.h. 5h Aufzeichnung ohne Überschreitung der 2GB Grenze sollten drin sein. Audio- und Videoanteile im File waren etwa gleich groß.
Ich habe vor, noch einen Test mit 720p also Standardauflösung 1280x720 zu machen. Erzielte Filegröße reiche ich dann nach.
Der Vergleich der Codecs x264 mit Xvid in puncto Quali vs. Dateigröße ist mir bislang nicht gelungen, da Camstudio bei Wahl des Xvid Codecs die Aufzeichnung mit der Fehlermeldung "Wave in error: Das angegebene Gerätehandle ist ungültig. in Stop()" gar nicht erst beginnt.
CamStudio 2.6c_r303 http://sourceforge.net/projects/camstudio/files/next/Camstudio-2.6c.7z/download
x264vfw Codec http://sourceforge.net/projects/x264vfw/files/x264vfw/37_2200bm_33968/x264vfw_37_2200bm_33968.exe/download
Folgende Einstellungen funktionieren bei mir (Windows 7, DualCore Prozessor) sehr gut:
Video: x264vfw, Q100, key200, frame25, 40
x264vfw config: ultrafast, CRF23, Loglevel=none
Audio: 22kHz, mono, 16bit, PCM(nicht änderbar!), Interleave1000ms, kein MCI!
Audio and Video Sync.: 500ms delay (die aufwendige Videokompression führte sonst zu zeitverschobenem Ton!)
Da bei mir Audio immer im PCM Format aufgenommen wird, egal welches Format ich einstelle, bleibt mir nur die Möglichkeit, den Ton nachträglich zu komprimieren, wenn ich kleinste Dateigrößen erreichen will.
Für spätere Audio Kompression z.B. mit Virtualdub/mp3 auf jeden Fall CBR (nicht ABR) benutzen, sonst unsynchroner Ton! CBR ist nur für 32kHz oder 44kHz verfügbar, also entweder später Samplingrate konvertieren oder gleich richtig mit 44kHz aufnehmen (größere Datei-> 2GB Grenze!)
Eine Testaufzeichnung eines 91 minütigen Webinars (mit Video) im Format 862x644 erbrachte vor der Audiokompression eine Größe von 544 MB, d.h. 5h Aufzeichnung ohne Überschreitung der 2GB Grenze sollten drin sein. Audio- und Videoanteile im File waren etwa gleich groß.
Ich habe vor, noch einen Test mit 720p also Standardauflösung 1280x720 zu machen. Erzielte Filegröße reiche ich dann nach.
Der Vergleich der Codecs x264 mit Xvid in puncto Quali vs. Dateigröße ist mir bislang nicht gelungen, da Camstudio bei Wahl des Xvid Codecs die Aufzeichnung mit der Fehlermeldung "Wave in error: Das angegebene Gerätehandle ist ungültig. in Stop()" gar nicht erst beginnt.
Comments
Standardeinstellung bei Xvid ist ja: Profile Xvid Home, Target quantizer 4.
Bei meinem Test erreiche ich für x264 mit Preset Ultrafast, Rate control CRF30
ähnliche Dateigrößen. Quali ist noch ok.
Profiles Xvid Home oder Xvid HD 720 machten keinen nennenswerten Unterschied,
also blieb ich auch für den 2. Test bei standard Xvid Home:
Profile Xvid Home, Target quantizer 1. Also beste Quali. Datei ist 2,4x so groß wie vorher.
x264 Einstellung Preset Ultrafast, Rate control CRF23 (CRF23 ist Standard) vergrößert die Datei nur auf das 1,6 fache bei zumindest gleicher Quali wie Xvid, wenn nicht besserer.
Zu erwähnen bleibt noch, dass das Bild gegen den Ton bei XVid etwas weniger nachläuft, also statt 500ms nur 400ms delay einzustellen ist. Ob der Ton bei langen Aufnahmen bildsynchron bleibt, habe ich für Xvid nicht getestet.
Bei obigen Angaben ist der Audioanteil aus der Dateigröße nicht herausgerechnet. Ich gebe daher hier nochmal den reinen Videoanteil an (der Audioanteil betrug immer 1.30 MB):
Testdatei 886x876, 30 sec:
Xvid 4: 0.70 MB
Xvid 1: 3.45 MB
x264 CRF30: 0.80 MB
x264 CRF23: 1.85 MB
Alles in allem fühle ich mich in der Annahme bestätigt, dass sich x264 gegenüber Xvid als der effizientere Codec beweisen werde. Da auf meinem Rechner auch die Zeitverzögerung bei Xvid nicht verschwindet, werde ich in Zukunft weiterhin mit x264vfw enkodieren.
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.
Ken
Außer Jawor´s Xvid habe ich keinen Xvid Encoder drauf.
Ich beziehe mich im Folgenden auf die Videos aus
http://camstudio.org/forum/discussion/1138/settings-for-high-quality-and-small-filesize#Item_2 :
An den fps liegt´s nicht. Gehe ich bei Xvid auf 20 fps runter, wird´s noch schlimmer. Die von Camstudio bei der Aufnahme angegebene "Input Rate" liegt bei x264 konstant bei 13,6 fps, bei Xvid nur bei 11,3 und fällt während der Aufnahme immer weiter auf unter 10 ab.
B-VOPs abzuschalten verbessert die Qualität bei Xvid deutlich. Es gibt keine Bildsprünge mehr. "Real time" Modus bewirkt eine minimale Verbesserung gegenüber "General purpose".
Den Bildnachlauf gegenüber der Tonspur kann ich für x264 nur nochmals bestätigen. Lässt sich aber durch das Delay gut ausgleichen.
Summa summarum bleibt die x264 Version immer noch deutlich besser.
Was die fehlende Audiokompression angeht: Ich finde es etwas unausgewogen, den Videoanteil mit dem letzten Schrei der Videokompression zu bearbeiten, den Audioanteil aber unkomprimiert zu lassen, obwohl doch schon mit dem vergleichsweise alten und kaum Rechenzeit erfordernden lame-mp3 der Audioteil um ca. 80% gegenüber 22kHz mono PCM (44kHz stereo PCM noch deutlich mehr) größenreduziert werden kann.
Alles in allem bin ich von Camstudio wegen des Aufwandes, der zur Anpassung betrieben werden muss, nicht gerade begeistert. Die notwendigen Einstellungsunterschiede, die sich anscheinend aus abweichender Hard-/Software der Benutzer ergeben, verleihen dem Programm das Flair einer Diva.
Aber dank x264vfw bin ich ja nun ein Happy Camper.
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.
Very well done, I think.
Ken
(Entscheidend scheint mir die während der Aufnahme angegebene "actual input rate" mit ca. 14 fps bei x264 und ca. 11 fps bei Xvid zu sein, die den Bildlauf bei x264 flüssiger erscheinen lässt. Ich deute das so, dass der x264 Encoder schneller arbeitet und deshalb weniger Einzelbilder "verliert".) Das stimmt so nicht, denn selbst wenn ich statt "ultrafast" mit "medium" encodiere, was schlimmste Folgen für den Bildlauf hat, bleibt die actual input rate bei 13fps.
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.
Thanks for this contribution. Very good indeed.
Ken
>Macromedia Flash, we’ll have the whole thing working perfectly.
Habe gerade hiervon einen Screencast erstellt:
http://www.adobe.com/au/products/hdvideo/hdgallery/assets/hdplayer.html?w=1280&h=760&vid=http://hdgallery.adobe.com/media/Opening_Day1_MAX07_720b.flv&n=Adobe Developer Video&f=720p
Ging einwandfrei, wo liegt bei Flash das Problem?
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.
Ken
Du schreibst, du hast Input rates von über 40. Müsste sich das auf den Screencast nicht dramatisch auswirken hinsichtlich weicher Bildfluss? D.h. dein Ergebnis sollte doch deutlich besser sein als meins?
Setze ich die Farbauflösung von 32 auf 16 bpp herunter, verdoppelt sich die input rate in etwa. Der Screencast ist viel fließender, aber immer noch nicht ganz so wie das Testvideo. Nehme ich mit Playback Rate 25 auf, ist das Ergebnis etwas schlechter, aber immer noch besser als 32bpp/playbackrate40. Sehr nachteilig bei 16 bpp sind die bei diesem Testvideo deutlich erkennbaren Farbraster.
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.
Ken
http://www.adrive.com/public/vBPTr9/time5-200.mpg
Ken
Settings for high quality and small file sizes
You need 2 files:
CamStudio http://sourceforge.net/projects/camstudio/files/next/Camstudio-2.6c.7z/download 2.6c_r303
x264vfw codec
The following settings work for me (Windows 7, dual core processor) very well:
Video: x264vfw, Q100, key200, frame25, 40
x264vfw config: ultrafast, CRF23, loglevel = none
Audio: 22kHz, mono, 16bit, PCM (! Unchangeable), Interleave1000ms, no MCI!
Audio and Video Sync. 500ms delay (led the elaborate video compression otherwise zeitverschobenem sound!)
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):
Test file 886x876, 30 sec:
Xvid 4: 0.70 MB
Xvid 1: 3.45 MB
x264 CRF30: 0.80 MB
x264 CRF23: 1.85 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.
---------------------------------------------------------
Thanks for the comment, Ken!
Except I have no Jawor's Xvid Xvid encoder on it.
I refer below to the videos from
http://camstudio.org/forum/discussion/1138/settings-for-high-quality-and-small-filesize#Item_2
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.
But thanks x264vfw I am now a happy camper.
Ken
Terry
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.
http://forum.sorensonmedia.com/forum/content.php?289-MPEG4-Preset-Customization
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?
But know you, you've probably already done some, right?
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.
Terry