Lagarith lossless codec

[benwaggoner]

Sounds like a good release. No new issues for me in limited testing, but After Effects still doesn't retain settings correctly.

[totya]

Originally Posted by benwaggoner

Sounds like a good release. No new issues for me in limited testing, but After Effects still doesn't retain settings correctly.

After Effects is x64 version?

[SirLagsalot]

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:

Compression:
Threads	Mode	1.3.20	1.3.22	1.3.24	1.3.25
single	RGB	180	146	145	118
multi	RGB	146	123	121	104
single	RGBA	218	177	177	143
multi	RGBA	179	163	148	131
single	YUY2	116	97	97	83
multi	YUY2	102	87	87	76
single	YV12	100	84	84	71
multi	YV12	89	76	75	64

						
Decompression:
Threads	Mode	1.3.20	1.3.22	1.3.24	1.3.25
single	RGB	203	134	127	96
multi	RGB	151	102	88	72
single	RGBA	266	177	169	127
multi	RGBA	187	133	122	103
single	YUY2	115	86	78	61
multi	YUY2	93	77	69	55
single	YV12	94	85	77	59
multi	YV12	71	76	68	49

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.

[benwaggoner]

Originally Posted by totya

After Effects is x64 version?

Yep. I filed a bug on this eight and then six years ago, for the 32-bit version .

[3ds]

Originally Posted by SirLagsalot

- Lend my assistance to FFMpeg to add full Lagarith decoding support.

Put Lagarith to other packs like FFMPEG is a very good idea! I found this: https://github.com/justinruggles/FFm...dec/lagarith.c So it this work already done?

Originally Posted by SirLagsalot

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

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

[SirLagsalot]

Originally Posted by 3ds

Put Lagarith to other packs like FFMPEG is a very good idea! I found this: https://github.com/justinruggles/FFm...dec/lagarith.c So it this work already done?

Right now they only have decoding support for YV12 encodings.

Originally Posted by 3ds

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.

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.

[TheRyuu]

Originally Posted by SirLagsalot

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

Oh right, seems I overlooked that somehow. Thanks for the update.

[Boogerlad]

lagarith 2.0! I would go for improved compression ratio though, because my cpu is fast enough, but my raid0 array lags behind.

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?

[SirLagsalot]

Originally Posted by ianken

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.

[Chikuzen]

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.

Originally Posted by Chikuzen

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?

[3ds]

Originally Posted by Boolsheet

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.

I don't know if there are any other porting projects for lagarith.

Is there any news about Lagarith on OSX? I found this:
http://trac.perian.org/ticket/198 but the decoder seems to be in libavcodec and perian:
https://github.com/FFmpeg/FFmpeg/tre...dec/lagarith.c
http://trac.perian.org/browser/ffmpe...dec/lagarith.c
isn't it?

[nm]

Originally Posted by 3ds

Is there any news about Lagarith on OSX? I found this:
http://trac.perian.org/ticket/198

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.

[qyot27]

Originally Posted by nm

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.

[tuqueque]

New Lagarith version 1.3.26
http://lags.leetcode.net/codec.html

Cheers.
tuqueque.

[benwaggoner]

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!

So many years of pain from that bug...

[dlnalover94]

is there any directshow filter that supports this codec for decoding?

[Chikuzen]

Originally Posted by dlnalover94

is there any directshow filter that supports this codec for decoding?

ffdshow and LAV Video Decoder