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.
Lagarith Corruption - any way to fix?
I recorded a bunch of videos with Lagarith Lossless in YV12. I was using a slightly out of date version at the time (1.3.23 I think). Only the top right of the video is visible, the rest is horribly corrupted. It LOOKS like there is valid data in there, just scrambled around. I can't seem to reproduce the corruption when trying to record again.
Comments
I just made one on using VirtualDub - listed near the bottom.
Terry
This is what the corruption looks like. I have it open in virtualdub, and tried converting it to another format but that didn't fix it.
Any more info?
Terry
Is there some sort of filter I could try in VirtualDub to see if it reconstructs it?
No pattern to it? So, you mean it does work sometimes without this anomaly? What could the difference be? What screen dimensions are you capturing? Could it be something like an odd-numbered width or a dimension that it just doesn't like?
I'll sleep on it and see if I can remember where I've seen this before.
Terry
Maybe you remember seeing this in an older version of Lagarith? I did notice I had been using an older version for some reason, v1.3.23, but again, I couldn't reproduce the problem even on that version of the codec.
CamStudio does not compensate by cropping in the manner you describe, but it does mess up and frustratingly adds a pixel to certain recording regions depending upon the version you are using - with certain cards on certain operating systems!!! So, don't depend upon CamStudio fixing anything - make certain the sizes are even-numbered right from the get-go.
This bug has been persistent since 2.5b, and every version we get either the fixed region being what's broken or the window region that's broken - they flip-flop as the fix for one must break the other one. I use Sizer to establish a Window region, and on one version I need to make my sizes 1279X719 to get 1280X720, but on the other version I have to do the same fix to the fixed region option instead, and my Sizer windows must be at the correct size of 1280X720. Maddening! But, your issue seems different according to some hazy recollection in the back of my mind. I'll remember eventually... I'll ask DigiDay what caused it for him, as I think I recall this happening to him when we were working with Lagarith way back when.
Terry
I tried quite a few tests with Lagarith v1.3.27 with 2.0 to see if I could replicate the file error shown, and found that I could not, but I was surprised otherwise by what I encountered.
First, using fairly high motion video in a test area of 848 x 480 , I reached the max 2Gb limit in just 4 min 50 seconds, so this has to be considered a suspect cause of such problems.
But the surprise (to me anyway) was that, in YUY2 and YV12 modes, CamStudio did indeed change deliberately set odd dimensions to AVI compliant even numbers when using the region setting, and in RGB, it recorded without changing the dimensions, and the result of that was a file which opens properly in Vdub, with no signs of corruption. In fixed region, the program has no trouble with an odd number in RGB, but produces a file creation error in the other two modes.
I’m guessing that the inconsistency may have something to do with changes made to the Lagarith codec in more recent versions, which may be having an unintended effect in the way that CamStudio runs. At any rate, in all of the files produced, even those with odd number pixels, the files loaded into Virtual Dub with no signs of problems, although one would never want to produce a file like that deliberately.
So, it looks to me like the codec version used has a problem, or the file size crept over the size limit.
Ken
--Jaw drops to floor-- How does it do that in Lagarith when it won't do it anywhere else???? Must be that the color space determines a different algorithm to be used in computing the width and height??? I wish that would be applied everywhere else!
Thanks a ton for testing this. I no longer have Lagarith on my new computer, because I've become such an Xvid fanboy that it's all I ever use anymore.
I really no longer think any lossless codec is worthwhile except in VERY rarified archive-related applications. But it does have its fans, so it would be great if it could be made to work every time.
Terry
As for the cropping, I've noticed that any codec that REQUIRES a certain dimension restriction seems to get it, my guess is that Lagarith in RGB mode doesn't actually need even-sized capture areas. I've noticed it will SAY it is capturing in some odd number if that's the window size it figures out, but the resulting file is actually sized properly. In the case with the corrupt files I have, they are sized properly (668x500)
As for version/file size, I was using a slightly older version, but the changelog didn't note any bug fixes related to my issue. I also kept my file sizes under 1.5GB
Actually, I think that the fact that Lagarith and CamStudio will produce a viewable video, even after one deliberately throws a wrench into the works as I did, is more of a curse than a blessing. It’s too easy to accidentally slip into another region setting or codec mode without realizing that you may be causing the program to accept and record odd number pixel images, which will appear perfectly normal when viewed, but cause problems further down the road.
Additionally, those who decide to use Lagarith should keep in mind that, if they later decide to use one of the many free video editors or media players which come with “onboard codecs”, there’s a very good chance that they will not be able to open the files which they create using Lagarith, so there’s a strong possibility that the files will have to be re-encoded anyway. This would be the case with editors like Avidemux and many versions of the VLC media player
I made static AVIs in every codec/mode combination using your pixel dimensions, and all worked perfectly, both in Vdub and for viewing using MPC (my VLC won’t open them) so I’m tempted to think that the problem has to do with your Lagarith version. If the problem is on the encoder side, I’m afraid those corrupted files you have may be lost. I would try to download a more recent version (decoder) before giving up on them, but at this point, I’d fear the worst.
As lossless codecs go, Lagarith is a bit slower encoder than Huffyuv, but better than most others.
I use nothing but Xvid MPEG 4 with CamStudio, During the tests I did with Lagarith, I also did a test MPEG 4 on the same streaming video material and then did a side by side comparison of the two. I can’t see any difference at all in the image quality, and the file size of the Xvid MPEG 4 is a small fraction of the Lagarith file.
Ken
I also use Xvid MPEG 4 exclusively now, and actually, it WON in the input frame-rate tests that came about when coldReactive was performing tests to compare processor priority, and discovered Xvid as the clear winner. DigiDay was using Lagarith for its good capture rate quite a while back, but uses MPEG 4 now, I believe (probably x.264 - I have to ask him. He needs his to work within Premier for editing.)
Here is coldReactive's test video (I include it in my CamStudio playlist at my YouTube channel - watch at Youtube at 480p.)
Terry
But, if the premise of high priority is merely to maintain the working characteristics of normal priority under varying conditions, the conclusion reached in the video has little meaning, since any variation would be caused by external elements not “directly” related to the codecs, other than the fact that some codecs are so resource intensive that they might be interfered with by other functions.
BTW I never use AVC/x264 anywhere - not for capture and not in processing. I’ve done side by side by side tests, and this almost always produces a less desirable result than the other options. Now, if someone were to download one of your tutorials at 480 from Youtube and did some analysis on it, they’d find what they have is an un-packed, x264 processed video which looks pretty darn good, so maybe it’s best to let the “Tube” do it and just download the result(?).
Anyway, how far OT can we possibly get here. Sorry, but I’m thinking that it looks bad for the corrupted Lagarith files. I do hope they were something that can be recreated with nothing more than a loss of work time.
Ken
Additionally, I've tried x264, it does create much better compression but runs at about 20% less actual framerate capture.
I also notice this guy is targeting 60FPS, I'm only targeting 15FPS. I know I can get a bit higher framerate if I up my target to 20 or 25ish, but that GREATLY increases the file size I get.
At this point I'm pretty resigned that the videos were lost that day - the audio is still there and I probably won't absolutely NEED the captured video, so its not terrible. I'll be keeping an eye out if that happens again.
When I did my tests with Lagarith, I used 5/200, because none of my editors wants to open Lagarith files, and it worked very well as is. I could have used Vdub in full process mode and made the input change from 5/30 to 200/30, but that would have resulted in a monster size file.
Terry’s Youtube tutorials are the only ones which contain correct setting information. If it hadn’t been for the good information he supplied, I would never have started using this program again.
The problem is that his videos are overwhelmed by a huge number of really bad ones, which send unsuspecting users down the wrong path and create a lot of unnecessary confusion.
Ken
But just to confirm what I understood you to be saying at the top of this thread, you did try running the bad files through Vdub in full processing mode? You would need to do that to get a full re-write of the header and new codec. (If it works, you’d get a good image but upside down).
Also, you do want to check the “use multi threading” box on the Lagarith configure panel. I found that it makes quite a difference.
Ken
Yes, I've tried running it through full processing into a different codec. The files themselves don't SEEM corrupt to any decoder (they don't report errors or warnings opening the file) its just the contents themselves are garbled.
Search will still find this easily, so staying on-topic isn't extremely important.
Terry