Lagarith 1.3.25 has been released, with several performance improvements. Overall, I see roughly a 20% encoding speed increase, and a 30% decoding speed verses version 1.3.24.
Below is a speed comparison of recent builds, with the time in seconds it took for Virtualdub to do a video analysis pass:

The test video was a 3000 frame 960x554 video. Encoding was done from a 12500kbps Xvid source; for RGBA it was fed through an Avisynth script which used mask to add an alpha channel based on the image. This biases the encoding results somewhat, since the Xvid decoding and mask times are included in the results. The test machine is an AMD Athlon 64 X2 4200+, using the 32bit build of Lagarith. Newer machines should see slightly better performance since the Athlon doesn't benefit from the added SSE2 routines.
The other significant change in this release is that settings are now stored in the Windows registry, this should make it more Vista and Windows 7 friendly.

At this point, I feel I've plateaued on optimizing Lagarith, and I am considering where to go next:
- Lend my assistance to FFMpeg to add full Lagarith decoding support.
- Start developing Lagarith 2.0, with the aims of supporting higher-bit depth colorspaces such as 48bit RGB, improved multithreading to take advantage of an arbitrary number of processors, and better performance overall.

Please let me know what you think of these options, as well as any other comments or suggestions about Lagarith.

- Start developing Lagarith 2.0, with the aims of supporting higher-bit depth colorspaces such as 48bit RGB, improved multithreading to take advantage of an arbitrary number of processors, and better performance overall.

I think the performance of Lagarith it very good and it which scenario is 48bit RGB good?

IMHO a good idea is to improve the compression ratio. Don't know if it make sence to look at Ut Video Codec Suite or to 7zip?

Some ideas (maybe some bad ideas ):
* Try to use identical picture parts from previous frames.
* Improve NULL Frames:
** Make them more compatibly (the readme says that some programs can't handle them)
** Use not only the last frame. Make it possible to use not only the last frame as NULL Frame. Store some reference frames which can be reuses later.

Some ideas (maybe some bad ideas ):
* Try to use identical picture parts from previous frames.
* Improve NULL Frames:
** Make them more compatibly (the readme says that some programs can't handle them)
** Use not only the last frame. Make it possible to use not only the last frame as NULL Frame. Store some reference frames which can be reuses later.

I'm leery of adding delta frames (besides null frames, which are part of the AVI spec), since it makes the codec less useful for video editing, and would significantly increase the complexity of the code.

Quote:

Originally Posted by TheRyuu

In your chart, do you by any chance have single/multi-threading reversed, all the single threaded numbers are higher than the multi-threaded ones.

The numbers are the time in seconds it took to run, so smaller is better.

Possible newb question: I seem to always get RGB otput from the decoder. It encodes and contains YUV, and I can use it in (for example) AVISynth with no problems. but playing the file directly or in graphedit shows it outputting RGB even though YV12 is set in it's config page (via Virtual Dub).

Is this just a DSHOw interop issue or is there some setting I can tweak?

Possible newb question: I seem to always get RGB otput from the decoder. It encodes and contains YUV, and I can use it in (for example) AVISynth with no problems. but playing the file directly or in graphedit shows it outputting RGB even though YV12 is set in it's config page (via Virtual Dub).

Is this just a DSHOw interop issue or is there some setting I can tweak?

The filter chain is probably just trying RGB before YV12. Try checking the 'Prevent Upsampling' box in the config dialog, that should prevent it from converting YV12 video to RGB on playback.

When VCM is used as a source filter in directshow, the graph cannot be constructed if VCM doesn't convert RGB.
thus, it is impossible to play Lagarith excluding RGB output on directshow mediaplayers(WMP, MPC, etc...) at now.

When VCM is used as a source filter in directshow, the graph cannot be constructed if VCM doesn't convert RGB.
thus, it is impossible to play Lagarith excluding RGB output on directshow mediaplayers(WMP, MPC, etc...) at now.

DMO decoder is required to construct the graph with YUV output.

AVISynth seems to be able to output YUV into graphedt, is that not VFW/VCM based?

I believe the lagarith source itself is Windows specific. I also read it uses a floating point arithmetic (or range?) coder, which makes portability less fun. Nathan Caldwell started a yv12 decoder for FFMpeg and they came up with something to emulate the problem with the entropy coder. The git of the fork is here. Looks like everyone is busy with higher priorities, so it's more likley the far future.
Once it gets finished, it probably gets comitted to FFMpeg and usable with perian (I'm assuming that's the ffdshow equivalent on OS X) or something.

The last comment on that ticket is three years old. FFmpeg/libav got a Lagarith decoder two years ago, but I guess it's still missing a few things, like support for other than YV12 colorspace (which SirLagsalot mentions above). YMMV.

The last comment on that ticket is three years old. FFmpeg/libav got a Lagarith decoder two years ago, but I guess it's still missing a few things, like support for other than YV12 colorspace (which SirLagsalot mentions above). YMMV.

The decoder was committed to SVN in January just before the project-splitting mess occurred, although the relevant code at commit time hadn't changed since the repo.or.cz Lagarith branch's last update in October 2009 (as observed above, a problem with solid color frames was fixed after commit).

FWIW, it works through mplayer/mplayer2 if you use a libavcodec that's newer than January 2011, so it's really down to getting mplayer/mplayer2 to build (Python was having some issues on OSX the last time I tried to build mplayer2 there). I attempted to build Perian a few months ago and see if I could expose the Lagarith decoder, but the build failed and I didn't feel like trying to troubleshoot it any further.

Woah! The switch from config to registry settings looks like it's fixed the ANCIENT bug in Adobe products where options weren't honored and everything was always RGB. I'm happily making a YV12 LAGS file from After Effects right now!