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.

German: Einstellungen für hohe Qualität und kleine Dateigrößen

edited November 2012 in Common Tips & Tricks
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.

Comments

  • edited November 2012
    Ich habe den Vergleich von x264 und Xvid jetzt hinbekommen. Xvid funktioniert bei mir nur, wenn ich als "Region" "Window" einstelle und auch dann nur bei manchen Fenstergrößen.

    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.

  • edited November 2012
    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.

    Ken
  • edited November 2012
    Danke für den Kommentar, 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. :)
  • 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.

    Very well done, I think.

    Ken
  • edited November 2012
    Danke für die Einstellungshinweise für den Xvid Encoder. Ich habe noch einen Screencast für Xvid entsprechend deinen Hinweisen (unrestricted, disable packed bitstream and b-VOPs, real time) angefertigt. Die Bitrate habe ich auf 8500 angehoben, damit die Dateigröße mit dem x264 Video vergleichbar ist. Siehe den anderen Thread.

    (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.
  • 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.

    Thanks for this contribution. Very good indeed.

    Ken
  • edited November 2012
    >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.

    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 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.

    Ken
  • edited November 2012
    Nochmal zur "actual input rate". Das Testvideo hat 24 FPS. Der Screencast (x264) ist bei "Playback Rate" 40 (actual input rate 14) aber fließender als bei 25 (actual input rate 11). Wie ist das zu erklären? Zumal der weiche Bildfluss des Testvideos noch lange nicht erreicht wird.

    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.
  • 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.

    Ken
  • 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.

    http://www.adrive.com/public/vBPTr9/time5-200.mpg

    Ken
  • English translation of original very valuable post from Google Translate:

    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.
  • edited January 2013
    Continued translations from Google Translate http://translate.google.com
    ---------------------------------------------------------
    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.
  • 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
  • I just posted that observation and question to the developers mailing list, Ken.

    Terry
  • @bmoreken

    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? :)
  • Nick,

    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
Sign In or Register to comment.