Lossless video codecs

[hoboX10]

I recently found this lossless video codec called MSU (http://compression.ru/video/ls-codec/index_en.html) and it appears to be better than a lot of other lossless codecs. However, the last update was from September 2005.

I also found another lessless video codec called YULS (http://www.yuvsoft.com/download/lossless-codec/) but it's maximum video resolution is 1024 x 768.

Is there any custom builds, or better alternate lossless codecs I can use? Both are supposed to be better than CorePNG, FFV1, and Lagarith. Apparently, those two are the top 2 lossless codecs out, but MSU has problems running with VirtualDub and YULS has that resolution limit.

Also, what do you guys think of this: http://www.h265.net/

[SeeMoreDigital]

Have you taken a look at the lossless versions of MPEG-4 AVC (H.264)?

[Midzuki]

Two more codecs: Camstudio (uses GZIP compression) and LJPG.

[LoRd_MuldeR]

Try FFV1, it provides even better compression than x264 lossless in my tests ;)

Compression of HuffYUV and lossless JPEG are significant worse than FFV1. The MSU codec is unbelievable slow, but the compression doesn't justify that speed at all!

Here are some results for the "Soccer" sample clip:
FFV1 100%, x264 105%, Lagarith 107%, LJPG 142%, HuffYUV 160%, MSU 198%

(Still wonder why x264 compresses worse than FFV1, because both use CABAC, but x264 has inter-frame prediction while FFV1 doesn't)

[MatLz]

Huffyuv.;)

[MiroLx]

You can also try MLC codec, at least it hasn't limit for resolution.

[SeeMoreDigital]

Try FFV1, it provides even better compression than x264 lossless in my tests ;)How about the "H.264 Lossless" encoder that comes with FFDshow?

[Dark Shikari]

How about the "H.264 Lossless" encoder that comes with FFDshow?That's the same thing...

[LoRd_MuldeR]

That's the same thing...

Can you explain why FFV1 compresses slightly better than x264 in "lossless" mode? At least with the samples I tested (real-life footage, uncompressed YUV source).

As far as I know, FFV1 uses the CABAC entropy coder taken from the H.264 standard, but in contrast to x264 it doesn't do any inter-frame prediction or motion compensation.

So shouldn't x264 compress better in theory? :confused:

[Dark Shikari]

Can you explain why FFV1 compresses slightly better than x264 in "lossless" mode? At least with the samples I tested (real-life footage, uncompressed YUV source).

As far as I know, FFV1 uses the CABAC entropy coder taken from the H.264 standard, but in contrast to x264 it doesn't do any inter-frame prediction or motion compensation.

So shouldn't x264 compress better in theory? :confused:No it shouldn't, because you're wrong.

FFV1 uses a completely different range coder than H.264, but that's not the reason; the reason FFV1 has better intra compression is because it uses median filtering and because its context model is utterly absurd (over one million contexts as compared to H.264's ~450). H.264's lossless coding is basically slapped on after-the-fact and is not very good compression-wise, at least not compared to what it could be.

On any source where inter compression is reasonably useful, x264 will beat FFV1.

[SeeMoreDigital]

Hmmm...

Using the same 50 second 720x576 MPEG-2 source, I generated lossless 720x576 encodes with x264 and FFV1. They came out at 100MB and 170MB respectively.

[LoRd_MuldeR]

Hmmm...

Using the same 50 second 720x576 MPEG-2 source, I generated lossless 720x576 encodes with x264 and FFV1. They came out at 100MB and 170MB respectively.

Probably because you were re-encoding from a pre-compressed (lossy) source clip?

Try one of these maybe:
* http://media.xiph.org/video/derf/y4m/soccer_4cif.y4m
* http://media.xiph.org/video/derf/y4m/720p/720p50_parkrun_ter.y4m


No it shouldn't, because you're wrong. FFV1 uses a completely different range coder than H.264

Well, I don't completely understand all the details, but the FFV1 technical docs clearly say:

3.6.1 Arithmetic coding mode

Context Adaptive Binary Arithmetic Coding (CABAC)

The coder is borrowed from H.264 and the reader is referred to that for further information, it is also noted that the author doesn't know if the coder is patented, so care must be taken if FFV1 is used in countries where software patents are legal. But even if CABAC turns out to be patent free there is still some risk that other parts of FFV1 are covered by patents. By just looking at the very long list of patents which cover other relatively simple standards it is shown that the patent offices seem to pass nearly everything. In many cases the patents cover basic operations like subtraction or taking the median of 3 integers in a specific case like motion vectors.

[akupenguin]

the reason FFV1 has better intra compression is because it uses median filtering and because its context model is utterly absurd (over one million contexts
173949 = (11*11*5*5*5+1)/2 symbol-contexts * 23 bit-contexts (assuming 8bit samples)

as compared to H.264's ~450).
And a bunch of those are for interlaced. So the number that counts is about 310.

Well, I don't completely understand all the details, but the FFV1 technical docs clearly say:
That was true when it was written 5 years ago.

[SeeMoreDigital]

Probably because you were re-encoding from a pre-compressed (lossy) source clip? Just performed another test. This time I converted the 720x576 MPEG-2 source to uncompressed RGB32 (1.47GB) and used this as the source.

Same result... x264 came out at 100MB and FFV1 came out at 170MB :)

[LoRd_MuldeR]

Just performed another test. This time I converted the 720x576 MPEG-2 source to uncompressed RGB32 (1.47GB) and used this as the source.

Same result... x264 came out at 100MB and FFV1 came out at 170MB :)

Well, maybe the kind of information/detail that would be costly (bit-wise) for x264 are already gone for good in the lossy MPEG-2 source.

Try one of the lossless/uncompessed sources I pointed to in my previous post. Going from lossy (e.g. MPEG-2) to lossless is kind of useless anyway ;)

[Dark Shikari]

173949 = (11*11*5*5*5+1)/2 symbol-contexts * 23 bit-contexts (assuming 8bit samples)Ah, seems I had a bit of off-by-a-zero there. Still of course an absurd number.

[hoboX10]

Lol epic thread hijack. ^_^ Just kidding, I'm learning a little, here and there, in this conversation.

Anyway... I take it there's no custom/alternate Lossless codecs here that you wouldn't find quickly on google? ._.

[nm]

Well, there are the japanese Ut (http://forum.doom9.org/showthread.php?t=143624) and AMV (http://amamaman.hp.infoseek.co.jp/english/amv2_e.html) codecs.

[mark0077]

Enjoyed reading this thread but when trying to encode a 1024 x 768 60fps clip from premiere to many lossless codecs I run into trouble.

Using ffv1 in avi, the exported clip plays the first 5 seconds and then crashes.
Using lossless jpeg in avi, the exported clip initially comes up as pure grey image, then shows a streaking effect and crashes.
Using H264 losslessin avi, the exported clip plays fine the whole way through, but its suspiciously small, and shows horrible video corruption the whole way through.

I am exporting a 60fps 1024 x 768 clip which exports fine completely uncompressed (not using ffdshow encoder).

My aim is to get my clip approx 30% smaller than the uncompressed lossless version so that my hdd can keep up with the clip, 4ghz core i7 should be enough I hope to decode this on the fly.

I am using ffdshow and mpc versions released a few days ago, 3060 and 1245. h264 lossless is the only one that I can actually see some output, although its badly garbled.

The charity event I will be playing the clip at is on the 19th of Sept, hoping someone can help me out before that.

[Dark Shikari]

Using H264 losslessin avi, the exported clip plays fine the whole way through, but its suspiciously small, and shows horrible video corruption the whole way through.Have you checked that your decoder supports H.264 lossless properly? FFDshow has only supported it since roughly this past January.My aim is to get my clip approx 30% smaller than the uncompressed lossless version so that my hdd can keep up with the clip, 4ghz core i7 should be enough I hope to decode this on the fly.x264 --tune fastdecode --qp 0 should compress well enough.

[poisondeathray]

mark0077 - what ffdshow build are you using? sometimes things get messed up with revisions; have you tried a different build?

You can try UT lossless codec, it decodes very fast for playback, much faster than lagarith/FFV1/huffyuv

[LoRd_MuldeR]

Using ffv1 in avi, the exported clip plays the first 5 seconds and then crashes.

Does it crash when encoding or when decoding? Also what application are you using?

I encoded a whole lot of clips to FFV1 with both, Avidemux and MEncoder, but didn't encounter any problems so far...

[mark0077]

I am using File - Export in Adobe Premiere. I am choosing the ffdshow video encoder and within its options, choosing things like ffv1, h264 lossless etc....

Someone suggested encoding to completely uncompressed and then using another tool to convert that to ffv1 etc but shouldn't the above method also work, just removes an extra step I would have to perform. I am using version 3060 of ffdshow.... using mpc-hc to play back the files then with ffdshow as the decoder.

As I say, the only lossless video codec that gives any sort of video output at all is h264 lossless. When encoded and played back I see some garbled frames that look somewhat like the original.... but the file size is alot smaller than I was expecting..... any obvious settings that I might be missing when encoding using ffdshow?

LoRd_MuldeR, when encoding to ffv1, my clip crashes after 5 seconds, but 5 seconds into the clip is the first time an actual video frame should be seen. In premiere I purposely left video content blank for the first 5 seconds.... mpc-hc crashes when getting to the 5 second mark, using ffdshow decoder.

[LoRd_MuldeR]

Well, this can be a problem in the version of ffdshow you are using or a problem in Adobe Premiere. It's impossible to say without further testing.

Just for test you could export it to an uncompressed AVI and then convert to FFV1 from there via Avidemux (or via VirtualDub + ffdshow).

[mark0077]

Thanks alot!! Using virtualdub to convert the uncompressed file seems to let me try all of the lossless codecs available in the ffdshow encoder. Much of my video content is RGB32 so I don't think huffyuv would give me lossless output? So far h264 lossless is giving me much smaller files than ffv1 but parts of the compressed clip that contain lots of information can drop from 60fps down to around 45.....

I will play with some of the h264 options to see what I can do. The cpu usage is very low... so I am unsure if those parts of the clip still demand high hdd read speeds. My hdd may still not be able to keep up... Any ideas without bothering you too much, what might help reduce the amount of hdd reads I will need.. Alot of the final clip plays fine at 60.0 fps perfectly, alot better than the uncompressed file which didn't reach 60fps for any of the clip.

EDIT: Damn, h264 lossless isn't outputting losslessly. When I playback the original uncompressed clip, the luminance ranges are correct, when playing the compressed clip, black appears greyish... This is with ffdshow outputting RGB32, set to assume input of full range... so does h264 lossless do some messing with the incoming rgb32 frames with respect to luminance, definitely not lossless to my eyes at the moment.

[LoRd_MuldeR]

Thanks alot!! Using virtualdub to convert the uncompressed file seems to let me try all of the lossless codecs available in the ffdshow encoder. Much of my video content is RGB32 so I don't think huffyuv would give me lossless output? So far h264 lossless is giving me much smaller files than ffv1 but parts of the compressed clip that contain lots of information can drop from 60fps down to around 45.....

You know that x264 only supports the YV12 color space? So at least the color-conversion will be "lossy" in a sense!

(Not sure whether FFV1 works with RGB32 data, will try to find out)

EDIT: Damn, h264 lossless isn't outputting losslessly. When I playback the original uncompressed clip, the luminance ranges are correct, when playing the compressed clip, black appears greyish... This is with ffdshow outputting RGB32, set to assume input of full range... so does h264 lossless do some messing with the incoming rgb32 frames with respect to luminance, definitely not lossless to my eyes at the moment.

It's lossless for sure! So what you are seeing probably is a playback problem. See this thread for a solution please:
http://forum.doom9.org/showthread.php?t=143689

[mark0077]

You know that x264 only supports the YV12 color space? So at least the color-conversion will be "lossy" in a sense!



Probably a playback problem! See this thread for a solution please:
http://forum.doom9.org/showthread.php?t=143689

Ah OK thanks. I'll try to find one that supports RGB32. As far as luminance, uncompressed clip shows deep blacks, compressed with h264 doesn't..... thanks for help anyways

[Dark Shikari]

Ah OK thanks. I'll try to find one that supports RGB32. As far as luminance, uncompressed clip shows deep blacks, compressed with h264 doesn't..... thanks for help anywaysThat's because of luma ranges, nothing to do with YV12.

You have to make sure that luma level conversion is done correctly when encoding from RGB to YV12.

[LoRd_MuldeR]

It seems that FFV1 as implemented in ffdshow's VFW interface offers full RGB32 support.

[mark0077]

In ffdshow encoder, outputting h264 doesn't give any specific options relating to luminance in the output file.... outputting to RGB32 with ffv1 works fine and gives me full luminance range, but is extremely slow being played back even though cpu usage is very low. ffv1 is my only option so far as it does give completely lossless, I just need to figure out how to make it decode at 60fps..... wonder if I am trying the impossible here. Tried changing keyframes from 10 to 1 but still playing back very slowly.

Everywhere in the chain I am using full range video, the uncompressed file is full range. The ffdshow output settings are set to assume full range input, and output for a Monitor... so unsure why h264 file is saved with limited luminance range and not full... especially because there is no option in the ffdshow decoder for it.. but I won't be using it anyways as its not RGB.

lossless jpeg gives larger file size than ffv1 obviously but when played back shows pure grey the whole way through. ffv1 still remains the only completely lossless codec thats working for me.... just need to see can I get it to play back at full speed ;)

[Dark Shikari]

In ffdshow encoder, outputting h264 doesn't give any specific options relating to luminance in the output file....Again, use x264 directly and use the --fullrange commandline option.

outputting to RGB32 with ffv1 works fine and gives me full luminance range, but is extremely slow being played back even though cpu usage is very low. ffv1 is my only option so far as it does give completely lossless, I just need to figure out how to make it decode at 60fps..... wonder if I am trying the impossible here. Tried changing keyframes from 10 to 1 but still playing back very slowly.FFV1 is slow. HuffYUV is much faster.

[mark0077]

thanks Dark, but h264 lossless isn't lossless if the original file is RGB32, and it outputs in YUV fullrange right? Same goes for HuffYUV if my assumption is right.

[Dark Shikari]

thanks Dark, but h264 lossless isn't lossless if the original file is RGB32, and it outputs in YUV fullrange right? Same goes for HuffYUV if my assumption is right.HuffYUV, despite the name, supports RGB.

[LoRd_MuldeR]

mark0077, use Avisynth input and let Avisynth do the required colorspace conversion:

AviSource("C:\UncompressedSource.avi")
ConvertToYV12(matrix="PC.601")

[mark0077]

Ah right, so huffyuv and ffv1 support RGB. HuffYUV in the ffdshow encoder doesn't give RGB option, only YV12 and YUY", maybe it could be a feature request I could put in.

Does h264 support RGB using command line also?

If not I will have to try huffyuv command line so that I can use RGB and play back at 60fps. Thanks alot guys.

[LoRd_MuldeR]

HuffYUV, despite the name, supports RGB.

The original HuffYUV, which apparently is used in ffdshow's VFW interface, didn't. I think only FF HuffYUV does...

[poisondeathray]

Are you sure you need RGB32? You are using alpha channel? Otherwise that extra 8bits requires more HD space, and slower to decode. If you are not using alpha, RGB24 should be fine (RGB mode, not RGB+A mode)

UT decodes about 3-5x faster for decode on a quad in YUY2 mode (I think the relative speed should hold for RGB and RGB+A mode), it should be more suitable for playback purposes

http://forum.doom9.org/showthread.php?t=143624

BTW I can confirm ffdshow vfw issues with Adobe Media Encoder CS4. (works fine in vdub, and other vfw encoders work fine in AME such as lagarith, UT, etc... only ffdshow is screwed up)

[LoRd_MuldeR]

Does h264 support RGB using command line also?

The H.264 format in general does support YUV 4:4:4 (no chroma subsampling). The x264 encoder doesn't yet! Not even from the commandline...

[mark0077]

Sweet you are all so helpful, and yes RGB24 is fine. If I can't get an RGB24 lossless encoder (ffv1 only has RGB32 option in ffdshow encoder and currently won't play back fast enough) that plays back at 60fps (going to try huffyuv in RGB mode using command line now), I'll have to settle for something less. I just want this as close to the original as possible as its going up on massive screens at the event.

[Leeloo Minaï]

According to your hardware configuration and what you want to do (get 30% disk space gain) : take UT codec.

It supports RGB colorspace both in 24 and 32 bpp, is faster than FFV1 to encode/decode, and then forget all the color range tricks...

Edit : poisondeathray was quicker than me ;)

[creamyhorror]

This is tangential, but what are good lossless codecs for importing into an NLE? So far it seems Lagarith is popular, but is there anything faster to decode and still bit-efficient? HuffYUV? And what's slower but more space-efficient? FFV1? (x264 with fastdecode tuning = good choice for certain footage? Only good for YV12 sources?)

Generally, I'd like to know which codecs would be good for each scenario.

[LoRd_MuldeR]

So far it seems Lagarith is popular, but is there anything faster to decode and still bit-efficient? HuffYUV?

HuffYUV should be faster than Lagarith, but won't compress as good as Lagarith.

And what's slower but more space-efficient? FFV1?

Yes.

x264 with fastdecode tuning = good choice for certain footage? Only good for YV12 sources?

x264 lossless should compress even better than FFV1 for suitable content, but that's certainly not always the case! I have clips that came out smaller with FFV1.

Also x264 is YV12 only. No RGB32/RGB24 support (I don't think H.264 can do RGB). YUV 4:4:4 would be possible in H.264, but isn't implemented in x264 yet.

[poisondeathray]

This is tangential, but what are good lossless codecs for importing into an NLE? So far it seems Lagarith is popular, but is there anything faster to decode and still bit-efficient? HuffYUV? And what's slower but more space-efficient? FFV1? (x264 with fastdecode tuning = good choice for certain footage? Only good for YV12 sources?)

Generally, I'd like to know which codecs would be good for each scenario.


I can vouch for UT for multithreaded decode speed. I use it alot for import into NLE's. Check out the thread link posted above for UT, there is a chart comparing some of the encoders for compression, encode speed, decode speed

There is a tradeoff between size and decode speed, and you will have to make that decision between how well it scrubs/edits vs. how much you value disk space/compression

[SeeMoreDigital]

Also x264 is YV12 only. No RGB32/RGB24 support (I don't think H.264 can do RGB). YUV 4:4:4 would be possible in H.264, but isn't implemented in x264 yet.Indeed.... Here is what MediaInfo reports about x264 lossless encodes generated using FFDshow: -Video
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High 4:4:4 Predictive@L3.1
Format settings, CABAC : No
Format settings, ReFrames : 1 frame
Width : 720 pixels
Height : 432 pixels
Display aspect ratio : 2.35:1
Frame rate : 25.000 fps
Resolution : 24 bits
Colorimetry : 4:2:0
Scan type : Progressive

Cheers

[LoRd_MuldeR]

Indeed.... Here is what MediaInfo reports about x264 lossless encodes generated using FFDshow: -Video
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High 4:4:4 Predictive@L3.1
Format settings, CABAC : No
Format settings, ReFrames : 1 frame
Width : 720 pixels
Height : 432 pixels
Display aspect ratio : 2.35:1
Frame rate : 25.000 fps
Resolution : 24 bits
Colorimetry : 4:2:0
Scan type : Progressive

Cheers

While x264 uses "predictive lossless", which is part of H.264's "High 4:4:4 Predictive" profile, it still doesn't support/use the YUV 4:4:4 colorspace ;)

(H.264 offers the YUV 4:4:4 in the "High 4:4:4 Predictive" profile, but it's simply not implemented in x264 yet)

[SeeMoreDigital]

While x264 uses "predictive lossless", which is part of H.264's "High 4:4:4 Predictive" profile, it still doesn't support/use the YUV 4:4:4 colorspace ;)

(H.264 offers the YUV 4:4:4 in the "High 4:4:4 Predictive" profile, but it's simply not implemented in x264 yet)Yes I know... That is what I was confirming to you!

[LoRd_MuldeR]

Yes I know... That is what I was confirming to you!

Alright :)

[creamyhorror]

Thanks for the replies, Lord Mulder and PDR.

That Ut codec looks like a real winner, even at this early stage. It's so much faster at Lagarith at decoding and even beats Huffyuv at the same compression ratio. A potential Cineform killer?

I'll definitely try it out the next time I use Premiere (which is admittedly rarely).

[mark0077]

utcodec solved all of my problems, completely lossless rgb24, plays back flawlessly, 1/4 file size of the original, thanks all.

[akupenguin]

Are you sure you need RGB32? You are using alpha channel? Otherwise that extra 8bits requires more HD space, and slower to decode. If you are not using alpha, RGB24 should be fine (RGB mode, not RGB+A mode)
FFV1 and FFVHuff don't support coding alpha, nevertheless they require the input video to have aligned pixels, i.e. be padded to RGB32.

[Max of S2D]

I use a codec bundled with Windows, Intel IYUV (the 4:2:0 variant). It divides the size of the original AVIs per two, so it doesn't compress really efficiently, but it still does a job good enough for me, as it does not hammer my CPU during the decoding.

[LoRd_MuldeR]

I use a codec bundled with Windows, Intel IYUV (the 4:2:0 variant).

Are you sure that one actually compresses the data? Or is it just smaller, because the RGB32 data is subsampled to YV12?

[qyot27]

HuffYUV, despite the name, supports RGB.
The original HuffYUV, which apparently is used in ffdshow's VFW interface, didn't. I think only FF HuffYUV does...
Regular old HuffYUV supports RGB (at least, 2.1.1 does (http://neuron2.net/www.math.berkeley.edu/benrg/huffyuv.html)). It was YV12 and adaptive huffman tables that ffvhuff added. But yeah, the HuffYUV coder in ffdshow's VFW interface doesn't have RGB offered. It can decode RGB-mode HuffYUV just fine, though.

[hoboX10]

Hmm so does is there any lossless codec that supports multi-core processors, with hyper-threading? Basically that works great with the intel core i7's?

My friend told me Lagarith only supports 2 threads.

[nm]

Ut and AMV are also multithreaded. But would the lossless codec really be such a bottleneck that it needs to be multithreaded, in your case? Usually rendering or re-encoding with a lossy codec will take a lot more time, and during editing playback only needs to be real-time.

[LoRd_MuldeR]

Hmm so does is there any lossless codec that supports multi-core processors, with hyper-threading? Basically that works great with the intel core i7's?

I don't think there is any Codec (or any software in general) that "supports" Hyperthreading. And there also should be no need for Hyperthreading-support on the software level!

Hyperthreading will "simulate" two logical CPU cores for each physical CPU core. This is done by running two threads on each physical CPU core.

To the Operating System (and to all software running on it) those logical cores will appear just like "normal" CPU cores.

So from the application's point of view, there is no difference between a Quadcore CPU with HT (4 physical cores, 8 logical cores) and a "real" Octocore without HT (8 physical cores).

Consequently any software that is properly multi-threaded will fully utilize a Hyperthreading CPU, as long as it creates enough threads to keep all (logical) core busy.

However a Hyperthreaded CPU with n cores wont achieve the same performance as a Non-Hyperthreaded CPU with 2*n cores (at the same clock speed).

[hoboX10]

I don't think there is any Codec (or any software in general) that "supports" Hyperthreading. And there also should be no need for Hyperthreading-support on the software level!

Hyperthreading will "simulate" two logical CPU cores for each physical CPU core. This is done by running two threads on each physical CPU core.

To the Operating System (and to all software running on it) those logical cores will appear just like "normal" CPU cores.

So from the application's point of view, there is no difference between a Quadcore CPU with HT (4 physical cores, 8 logical cores) and a "real" Octocore without HT (8 physical cores).

Consequently any software that is properly multi-threaded will fully utilize a Hyperthreading CPU, as long as it creates enough threads to keep all (logical) core busy.

However a Hyperthreaded CPU with n cores wont achieve the same performance as a Non-Hyperthreaded CPU with 2*n cores (at the same clock speed).

Well is there any ones that support multi-cores?

[LoRd_MuldeR]

Well, did you read nm's post? He names at least two lossless Codecs that are multi-threaded.

Also x264 certainly will scale up to eight cores and there definitely are H.264 decoders that are multi-threaded (ffmpeg-MT, CoreAVC, DivX H.264 Decoder).

[Leeloo Minaï]

This test does not reflect real usage at all.
Lagarith codec is known to have data corruption problems and YULS has a resolution limitation to 1024x768.

Take some time to try other codecs and forge your own opinion : if we are several users to recommend UT or FFV1 codec, there is a good reason, but not because we have read an 2-year old theorical test...

[(*|*)]

what lossless codec do you recommend for capturing/editing?

[nm]

Ut Video Codec Suite is a good choice for capturing and editing If your toolchain supports VFW. Ut is optimized for speed on modern multi-core CPUs and it's also open-source (GPLed).

See:
http://forum.doom9.org/showthread.php?t=143624
http://umezawa.dyndns.info/wordpress/