[HD 1080p24 Challenge] MPEG2, VC-1 and H264 with real uncompressed source

[Dark Shikari]

I have a really annoying problem...

I'm running the SSIM test and the number printed in the csv file by the SSIM test is not the number printed on the screen.

The screen value (shown in the output) is around 0.98-0.99 in most frames and is correct. The value in the saved file is around 0.5-0.8 and is completely wrong... but they're for the same frame!

What could be wrong? I'm using the correct script/etc.

[akupenguin]

02.08.2007 - Max adaptative bframe at 7 for VC1
And why only VC1? While I haven't seen the HD-Blu-DVD-Ray spec, there is no possible technical reason to limit number of B-frames in MPEG2 or H264 either.

[Sagittaire]

I see that Sagittaire has made the motion vector range for VC-1 unlimited. Actually, he was correct to begin with. The motion vector range is limited in the VC-1 specification for AP@L3 to -1024/+1023.75 horizontal and -256/+255.75 vertical.

Ron

mvrange 1 setting is adaptive and can search up to 512x256 pixels. We tested with mvrange 3 (1024x512 pixels in my memory) but this setting don't change the quality like for the other codec. For Libavcodec for example I use motion at +/- 128 pixel for V/H range and seem really not a problem for libavcodec ... ;-)

[Sagittaire]

And why only VC1? While I haven't seen the HD-Blu-DVD-Ray spec, there is no possible technical reason to limit number of B-frames in MPEG2 or H264 either.

I would have to keep the bframe at 2 for the VC1... lol

Why speak about completely useless setting for quality ? max GOP lenght or max buffer are by far more important than large bframe number or large motion vector range.

[Dark Shikari]

Well though SSIM still isn't working right the OPSNR (Global PSNR) as reported by x264 is 46.37 at 6001kbps, which beats the current one.

I'll try to get SSIM working before I submit the logs.

[Sagittaire]

I have a really annoying problem...

I'm running the SSIM test and the number printed in the csv file by the SSIM test is not the number printed on the screen.

The screen value (shown in the output) is around 0.98-0.99 in most frames and is correct. The value in the saved file is around 0.5-0.8 and is completely wrong... but they're for the same frame!

What could be wrong? I'm using the correct script/etc.

You have certainely a source-encoding desynchro somewhere.

[Dark Shikari]

You have certainely a source-encoding desynchro somewhere.
Actually, there was a one-frame sync issue before, but I fixed it long ago.

Using "subtract" shows a nearly perfect encode (with a tiny bit of noise showing the difference). And the SSIM reported on the screen is correct. Its just that the SSIM reported on the screen isn't the SSIM written to disk.

It also can't be a desynchro because, for example, there is a very long section where it gives me 0.87 SSIM. That section has some scenes with very low motion, where desynch would give very high SSIM. And it has scenes with very high motion, where desync could give as low as 0.5 SSIM. But the SSIM is nearly constant...

[Sagittaire]

Actually, there was a one-frame sync issue before, but I fixed it long ago.

Using "subtract" shows a nearly perfect encode (with a tiny bit of noise showing the difference). And the SSIM reported on the screen is correct. Its just that the SSIM reported on the screen isn't the SSIM written to disk.

It also can't be a desynchro because, for example, there is a very long section where it gives me 0.87 SSIM. That section has some scenes with very low motion, where desynch would give very high SSIM. And it has scenes with very high motion, where desync could give as low as 0.5 SSIM. But the SSIM is nearly constant...

try to fix that with xxx=AssumeFPS(xxx,25) for the source and the encoding.

[akupenguin]

Why speak about completely useless setting for quality ? max GOP lenght or max buffer are by far more important than large bframe number or large motion vector range.
To simplify the rules; don't impose arbitrary constraints that don't actually matter.
I would be happy with a comparison of unconstrained VBV and GOP, but those actually are constrained in some circumstances so it's up to you what you want to compare.

[Dark Shikari]

try to fix that with xxx=AssumeFPS(xxx,25) for the source and the encoding.
Changed nothing...

1.000000,0.000000
1.000000,0.000000
1.000000,0.000000
1.000000,0.000000
1.000000,0.000000
1.000000,0.000000
1.000000,0.000000
1.000000,0.000000
1.000000,0.000000
1.000000,0.000000
1.000000,0.000000
1.000000,0.000000
1.000000,0.000000
1.000000,0.000000
1.000000,0.000000
1.000000,0.000000
1.000000,0.000000
0.859322,0.000007
0.948180,0.000550
0.965571,0.005960
0.964541,0.019131
0.963200,0.042045
0.959394,0.074574
0.956373,0.114236
0.953453,0.158541
0.949925,0.204425
0.946661,0.251496
0.942690,0.297007
0.941106,0.339777
0.939467,0.379720
0.937427,0.417226
0.935186,0.451787
0.932795,0.483719
0.930243,0.513539
0.927655,0.541749
0.926063,0.568288
0.924068,0.593254
0.921780,0.616798
0.920453,0.638959
0.917377,0.660497
0.914097,0.681218
0.912452,0.700811
0.911031,0.719925
0.909452,0.737590
0.907213,0.753739
0.905705,0.768649
0.903450,0.782323
0.904477,0.795505
0.899458,0.806337
0.900177,0.817413
0.896104,0.820151
0.896978,0.821368
0.896090,0.822303
0.893987,0.822636
0.892555,0.823039
0.893955,0.824572
0.892872,0.825510
0.891226,0.825848
0.892669,0.827248
0.891866,0.827950
0.890329,0.828055
0.891505,0.829170
0.890780,0.829560
0.889334,0.829460
0.890810,0.830348
0.890095,0.830587
0.888991,0.830056
0.888855,0.830063
0.890288,0.829152
0.891272,0.829616
0.890589,0.829536
0.888957,0.828590
0.890311,0.828816
0.889489,0.828476
0.888026,0.827348
0.889213,0.827524
0.888319,0.827035
0.886644,0.825562
0.887876,0.825454
0.886921,0.824555
0.885153,0.822932
0.884522,0.822114
0.885601,0.820418
0.886591,0.820470
0.886132,0.819940
0.885308,0.818468
0.887169,0.818338
0.886982,0.817383
0.885903,0.815621
0.887288,0.815311
0.886701,0.814147
0.885179,0.812256
0.886386,0.811729
0.885384,0.810263
0.883742,0.807864
0.882930,0.806333
0.884083,0.803457
0.884996,0.802472
0.884227,0.800705
0.882626,0.797564
0.883727,0.795909
0.882473,0.793082
0.880607,0.788911
0.881234,0.786163
0.879552,0.781846
0.877459,0.776738
0.878202,0.773359
0.876956,0.769064
0.875143,0.763991
0.874693,0.760527
0.875399,0.755677
0.876061,0.753632
0.875119,0.751138
0.873281,0.747208
0.874164,0.745321
0.872700,0.742762
0.870950,0.738418
0.872100,0.735692
0.871463,0.732210
0.869850,0.727695
0.870702,0.725389
0.868842,0.721745
0.867508,0.717171
0.867527,0.714998
0.869043,0.710753
0.870287,0.708823
0.869943,0.706475
0.868544,0.702917
0.869265,0.700860
0.867461,0.697816
0.866388,0.691727
0.867583,0.690574
0.867263,0.688661
0.866101,0.685302
0.867528,0.683905
0.866755,0.681107
0.865166,0.677110
0.865006,0.674474
0.866233,0.669985
0.867673,0.668536
0.867287,0.666189
0.866106,0.662506
0.868536,0.661107
0.869133,0.658654
0.868697,0.654937
0.870590,0.653757
0.870174,0.651497
0.868936,0.648008
0.870631,0.647035
0.870131,0.644883
0.868908,0.641559
0.868618,0.639710
0.870395,0.636294
0.871375,0.635723
0.871137,0.634330
0.869787,0.631031
0.871178,0.630320
0.870394,0.628514
0.868904,0.625036
0.870283,0.624187
0.869591,0.622313
0.868028,0.619059
0.869435,0.618591
0.868695,0.616717
0.866955,0.613454
0.866402,0.611726
0.867358,0.608393
0.868482,0.607952
0.867926,0.606767
0.866460,0.603474
0.867545,0.603054
0.866240,0.601419
0.864043,0.598229
0.864654,0.598152
0.864261,0.597085
0.863747,0.594630
0.866323,0.595315
0.866718,0.594632
0.866297,0.592426
0.866477,0.592238
0.867817,0.589712
0.868607,0.590823
0.868047,0.590876
0.866585,0.588671
0.867504,0.589442
0.866959,0.588935
0.866042,0.586316
0.867893,0.587106
0.867537,0.586249
0.866481,0.583842
0.867848,0.584737
0.867824,0.584439
0.866838,0.582154
0.867023,0.581637
0.868089,0.578876
0.869407,0.579969
0.869427,0.580009
0.868813,0.577788
0.871144,0.578705
0.872251,0.578284
0.872815,0.576089
0.875847,0.576976
0.877001,0.576480
0.877246,0.574208
0.879627,0.575125
0.880108,0.574610
0.878661,0.572402
0.877614,0.572274
0.877701,0.569543
0.877494,0.570809
0.876097,0.570986
0.873773,0.569075
0.873833,0.570281
0.872530,0.570372
0.870694,0.568181
0.871458,0.569215
0.870899,0.568870
0.869658,0.566725
0.870816,0.567685
0.870534,0.567303
0.870022,0.565039
0.870907,0.564865
0.872807,0.562268
0.874055,0.563231
0.873762,0.563200
0.872144,0.561069
0.874467,0.561269

is the first ~200 frames of SSIM even though x264 reported an SSIM of over 0.9885 :)

[Sagittaire]

To simplify the rules; don't impose arbitrary constraints that don't actually matter.

I used this limitation for H264 because in practice x264 don't work with more than 2 bframes (trahald nal_hrd and pulldown patch, pyramid bframe) and x264 produce the best result a this test.



I would be happy with a comparison of unconstrained VBV and GOP, but those actually are constrained in some circumstances so it's up to you what you want to compare.

Well in fact it's 9 781 for MPEG2 (MP@HL), 14 745 for VC1 ... but 30 000 Kbits is perhaps complaint for HDDVD too (BD use 30 000 Kbits). I don't have clear answer on this subject: Sergey A. Sablin say 30 000 Kbits and benwaggoner say 14 745 for all the video codec. 30 000 vs 14 745 will not change the result for 6/20 Mbps (average/max) encoding but it's not the case for 18/28 Mbps encoding.

[Sagittaire]

is the first ~200 frames of SSIM even though x264 reported an SSIM of over 0.9885 :)

You can upload your file somewhere ... ?

[Dark Shikari]

You can upload your file somewhere ... ?
The output .h264 stream? Its quite large... I'll see if I can find a place. Do you have an FTP I could dump it on overnight?

Edit: Found a site of that should be able to barely fit it with a few megabytes margin. I'll post the link in the morning.

[Dark Shikari]

Download the raw H264 stream, 6Mbit (http://tjhsst.edu/~jgarrett/6000_3.h264)

[pandy]

B - Rules

Rule 1 : Source

Uncompressed source is available Here (http://orange.blender.org/blog/original-lossless-source-available/) for reproduce the test.
Open source Elephant Dream movie, video 1920*1080 PNG lossless, audio 5.1 Flac lossless, 15 691 frames



Hm. i think that ED is not optimal source due their artificial character.
Please also use a raw sources which represent other than artificial generated images sources (i believe that over 60 - 70% sources are CG free).

eg such as
http://www.ldv.ei.tum.de/Members/tobias/sequences

PS
Please use also interlace not only progressive source.

[Dark Shikari]

Hm. i think that ED is not optimal source due their artificial character.
Please also use a raw sources which represent other than artificial generated images sources (i believe that over 60 - 70% sources are CG free).

eg such as
http://www.ldv.ei.tum.de/Members/tobias/sequences

PS
Please use also interlace not only progressive source.
The problem with live-action footage is that often it has a lot of noise when unprocessed, meaning that SSIM is really testing the noise-retention ability of the codec, rather than quality.

[MfA]

SSIM cares much less about noise than PSNR.

As for interlaced, lets just pretend it doesn't exist and stick to 720p50/60 ... you can't test interlaced content in isolation, the technology necessary to display it on modern displays (motion compensated deinterlacing) will interact with the coding artifacts and we don't have equivalent technology available to do the testing in software. Besides, interlacing is the spawn of evil.

[Dark Shikari]

Anyways can someone check out my above posted H.264 stream? Since I can't get the SSIM to work.

Since the OPSNR is better than the one currently posted and the optimization I used is tuned for SSIM, not PSNR, it should be pretty good...

[Tack]

[...]the technology necessary to display it on modern displays (motion compensated deinterlacing) [...]Do any modern consumer level displays do motion compensated deinterlacing? I thought even the more higher end consumer displays were pretty much motion adaptive across the board.

[Sagittaire]

Anyways can someone check out my above posted H.264 stream? Since I can't get the SSIM to work.

Since the OPSNR is better than the one currently posted and the optimization I used is tuned for SSIM, not PSNR, it should be pretty good...

Test in progress ... frame at 12 000. End of the test in 12 min.

[Sagittaire]

Annexe - Update

05.08.2007 - Max adaptative bframe at 7 for VC1, H264 and MPEG2
04.08.2007 - Unlimited range vector for VC1
03.08.2007 - Encoding with libavcodec at 18 Mbps
02.08.2007 - Max adaptative bframe at 7 for VC1
01.08.2007 - Complete Test with x264, pep and libavcodec

will coming ... if you want ... !!!
All the developpers are wellcome ... !!?

[buzzqw]

could you update the encoding string on first page ?

thanks!

BHH

[Sagittaire]

Download the raw H264 stream, 6Mbit (http://tjhsst.edu/~jgarrett/6000_3.h264)

your encoding produce 89.73031441
My encoding produce 89.54523791

[Dark Shikari]

your encoding produce 89.73031441
My encoding produce 89.54523791
\o/ It worked, mine's top now :cool:

For the curious, I used my optimized SSIM-SATD x264 build (patched with nal-hrd) with the following commandline (third pass):

./x264HRDOpt.exe --threads 1 --thread-input --keyint 14 --min-keyint 2 --vbv-maxrate 20000 --vbv-init 1.0 --vbv-bufsize 14745 --mvrange 511 --merange 64 --level 4.1 --nal-hrd --bframe 2 --b-rdo --bime --weightb --ref 3 --mixed-refs --direct auto --deblock -1:-1 --qpmin 1 --bitrate 6000 --pass 3 --stats "x264_stat.log" --qcomp 0.75 --ipratio 1.10 --pbratio 1.25 --partitions "all" --8x8dct --me "umh" --subme 7 --no-fast-pskip --trellis 2 --aud --sar 1:1 --progress -o 6000_3.h264 elephantsDream.avs

The --merange was probably unnecessary and slowed it down a lot given my very slow ME function.

[arfster]

Hm. i think that ED is not optimal source due their artificial character.
Please also use a raw sources which represent other than artificial generated images sources (i believe that over 60 - 70% sources are CG free).

eg such as
http://www.ldv.ei.tum.de/Members/tobias/sequences


I'd agree with this - you're always going to get the above objection unless you have some high quality outdoors origin stuff. At the very least you'd end up with two sets of data, and some potentially interesting comparisons.

Does anyone know what would be the best approach for encoding the above though? Just feed them into avisynth, or is some processing needed beforehand? I'd be willing to do it anyway, got a couple of fast PCs here - just would be nice to get some expert advice before encoding away for several days :-)

[Inventive Software]

This is also why I suggested about a film grain filter for the AviSynth script, but you'd need something that generates the same grain each time AviSynth is loaded.

[pandy]

The problem with live-action footage is that often it has a lot of noise when unprocessed, meaning that SSIM is really testing the noise-retention ability of the codec, rather than quality.

Hmmm - noise is natural part of video, noise is good coz:
- subjective sharpening
- less banding
- bitrate stabilisation

So proper amount of noise is very important but the problem is how many noise we need to achieve a good, high quality video.
Noise itself is not problem.

[pandy]

This is also why I suggested about a film grain filter for the AviSynth script, but you'd need something that generates the same grain each time AviSynth is loaded.

Hm... better idea is to generate uncompressed noise video clip (as a reference) and add to the another clip. Always the same, equal for all.

[Dark Shikari]

your encoding produce 89.73031441
My encoding produce 89.54523791
Can you update the first post with the new numbers?

[akupenguin]

Hmmm - noise is natural part of video, noise is good coz:
- subjective sharpening
Add it at playback time.
- less banding
Noise hides banding if it's added at playback time.
Noise increases banding at any given bitrate if it's added before encoding, because it takes bits away from the actual content.
- bitrate stabilisation
You mean, wastes bitrate equally everywhere. And why do you care about a "stable" bitrate anyway? You don't see bitrate, you see quality.

Noise is always a problem. The only argument for including it in a test is that non-CG movies have a certain amount of unavoidable noise, and you want the test to reflect the imperfect real world.

[Inventive Software]

What about commercial CG movies like The Incredibles, Finding Nemo, and the like? They AFAIK don't have noise....

[Sharktooth]

They have added noise (studios are used to that) and since there arent uncompressed sources available there will sourely be DCT noise from codecs...

[Sagittaire]

Can you update the first post with the new numbers?

Unfortunaly there are a bug from nah_hrd flag for trahald patch. StreamEyes show big overflow. Anyway I think that it's just HRD flags problem and stream is certainely internaly HDDVD compliant. Anyway no doubt that your build obtain better SSIM than my build.

[Dark Shikari]

Unfortunaly that are a bug from nah_hrd flag for trahald patch. StreamEyes show big overflow. Anyway I think that it's just HRD flags problem and stream is certainely internaly HDDVD compliant. Anyway no doubt that your build obtain better SSIM than my build.
Wait, I used the same NAL_HRD patch that you did; why did mine have problems and yours didn't?

[Sagittaire]

Wait, I used the same NAL_HRD patch that you did; why did mine have problems and yours didn't?

I use in fact an old build with different NAL_HRD patch. Anyway no problem for your patch itself: the SSIM is better.

[Dark Shikari]

I use in fact an old build with different NAL_HRD patch. Anyway no problem for your patch itself: the SSIM is better.
Ah so the current NAL-HRD doesn't actually work right anyways :p

Yeah, I'm still trying to improve the SSIM. I'm currently working on optimizing the metric used by RDO, hopefully that will yield some results.

[akupenguin]

Yes, the reason the HRD patch isn't applied is that it doesn't attempt to generate the right numbers, it just fills in the HRD fields with something. And I don't know how to compute the right numbers either, so I can't fix it.

[Sagittaire]

Yes, the reason the HRD patch isn't aplpied is that it doesn't attempt to generate the right numbers, it just fills in the HRD fields with something. And I don't know how to compute the right numbers either, so I can't fix it.

I will report the bug to trahald ...

[benwaggoner]

I'm still trying to track down some film source with clear rights I can distribute for parallel testing with some other content. Looks like I've got an angle on something we shot ourselves.

But before I spend a bunch of time on getting the assets unarchived and edit something together, I just wanted to make sure folks aren't going to immediately object to anything I do on the grounds that I cherrypicked :).

So, this worth me spending some (probably a bunch!) of time on?

[Sagittaire]

I'm still trying to track down some film source with clear rights I can distribute for parallel testing with some other content. Looks like I've got an angle on something we shot ourselves.


Not possible to have trailer from major studio for example ... ???

Anyway why not make encoding for this source in a first time. I want see if my vc1 profil is really bad ... lol.


4) Why not ask Microsoft for VC-1 encoding advice? We would've been happy to help. At the very least we could've provided advice on encoding settings.

... but no encoding from MS at this time.

[Golgot13]

Not possible to have trailer from major studio for example ... ???

Yes, it is very hard to have some right (I know, need to explain many time it's for test
and there is no money...). It is same for trailers because major studio need agreement from producer.


Anyway why not make encoding for this source in a first time. I want see if my vc1 profil is really bad ... lol.

... but no encoding from MS at this time.

May be MS team are in holiday but Ben is here :)
I have the same result than you, Sagitaire, with the vc1_enc on PEP solution (1.06).
I think PEP can not do a better quality (near of surely).


I can give some HDV footage from Tri-CCD camcorder but it is MPEG2 HD video file.



Regards,



Golgot13

[benwaggoner]

Not possible to have trailer from major studio for example ... ???
As uncompressed source with wide-open redist rights? That's a lot to ask, and I haven't found one yet.

Trailers are also somewhat different than a movie, which can change things. A LOT more time spent in fades to/from blacks and in title slides, a lot less in credits. Often more shots...

Anyway why not make encoding for this source in a first time. I want see if my vc1 profil is really bad ... lol.
That'll happen in parallel, but folks a pretty heads down this week.

[benwaggoner]

So, it looks like the source I could share is right now about 45 minutes of 10-bit 4:2:2 D5 telecined from 35mm. It's stuff we shot ourselves, of a tall ship (Lady Washington) in the Puget Sound. Lots of shots of water, the ship, sailors doing stuff on the ship. So, I'm thinking about doing something like:

10 total minutes
Focusing on the more complex bits, but with a variety to stress rate control.
Matted to 1.85:1
With some fades to/from black and cross dissolves
Some kind of motion graphics opening credits and scrolling credits at the end. I'll keep those short, to have the same ballpark percent of credits as a typical film.

How does that sound? Not like there are any explosions in there, but some good frames with a nice combination of high detail (rigging) and flat gradients (the sky). Some good handheld stuff.

[Inventive Software]

That sounds excellent! Gimme...... :D

[zambelli]

So, it looks like the source I could share is right now about 45 minutes of 10-bit 4:2:2 D5 telecined from 35mm.
Ben, do you plan on subsampling that down to YV12? I suppose we could share out v210 copies, but the download sizes would be ridiculous and the ambiguity of having everybody do their own downsampling to 4:2:0 would be too great to yield consistent results.

[Sagittaire]

Ben, do you plan on subsampling that down to YV12? I suppose we could share out v210 copies, but the download sizes would be ridiculous and the ambiguity of downsampling to 4:2:0 would be too great to yield consistent results.

compression with really efficient lossless codec (open source like ffv1 for example) could be really usefull here.

[zambelli]

VC1 stream here use internal PP flags. Internal flags adjust automatically the PP decoding for the DMO decoder if you don't use Force Process Mode command line registry and I don't use this command registry.
Oh, I wouldn't be so sure that the DMO decoder respects the PP flags in the VC-1 bitstream. :) But since neither CoreAVC nor FFfdshow do postprocessing for H.264 by default, it's probably best if VC-1 postprocessing is forced OFF in the DMO too. I always disable it when doing any PSNR/SSIM tests.

This test IS made from raw uncompressed source.
On that subject... The Elephants Dream PNGs, while uncompressed RGB, are not perfect. The downsampling to 8-bits per channels was done with significant banding in dark areas. Not that it really affects the encoder comparison, but if this was an HD-DVD/BluRay production competition, this "ED" source would be a great example of a poor master. :)

The big problem is buffer: 9781 for MPEG2, 14745 for VC1 and perhaps 30000 for H264?
I'm pretty sure we established that the buffer size was the same for all 3 codecs in the HD-DVD spec:
http://forum.doom9.org/showthread.php?p=881160#post881160

I see that Sagittaire has made the motion vector range for VC-1 unlimited. Actually, he was correct to begin with. The motion vector range is limited in the VC-1 specification for AP@L3 to -1024/+1023.75 horizontal and -256/+255.75 vertical.
Well, if that's the maximum, there's no point in limiting it. And in a 1920x1080 encode that range would be pretty useless anyway. If an object is moving that much between frames, it might be time for an I frame. ;)

mvrange 1 setting is adaptive and can search up to 512x256 pixels. We tested with mvrange 3 (1024x512 pixels in my memory) but this setting don't change the quality like for the other codec. For Libavcodec for example I use motion at +/- 128 pixel for V/H range and seem really not a problem for libavcodec ... ;-)
In the Microsoft VC-1 encoders only one of the MV Range settings is adaptive - the rest are fixed. And the adaptive setting doesn't even go all the way up to maximum. It's generally always best to use the adaptive MVRange setting because setting too large of an MVRange can actually result in false positive matches - and takes a very long time.

but no encoding from MS at this time.
Sorry, been busy. I'll try to encode something when I catch some free tme.

[zambelli]

compression with really efficient lossless codec (open source like ffv1 for example) could be really usefull here.
You don't have to worry about that, Ben likes to talk about Lagarith nearly as much as he likes to talk about VC-1. ;)

[benwaggoner]

Ben, do you plan on subsampling that down to YV12? I suppose we could share out v210 copies, but the download sizes would be ridiculous and the ambiguity of having everybody do their own downsampling to 4:2:0 would be too great to yield consistent results.
I was thinking an IYUV .AVI file, for the reasons you suggest.

Although i don't know that the download size would be that much better :). I'd obviously .zip it up as well.

[benwaggoner]

compression with really efficient lossless codec (open source like ffv1 for example) could be really usefull here.
Yeah, Lagarith would be the other thing I might use. The nice thing about IYUV is that it'll decode on Mac as well.