[x264-devel] I444 support

[Neil Woodall]

I think the issue with respect to JPEG 2000 is that wavelet  
compression will work much better on natural scenes than a DCT based  
CODEC. If you want lossless and no sticky artifacts (transmission  
errors), then most feel that JPEG2000 is a better solution. However,  
the difference in quality for a given bit rate is really determined by  
the errors in transmission. If you use the full H.264 standard, you  
can simply transmit the picture twice. The decoder will use the second  
picture (slices or packets...I'm not sure without rereading) if errors  
are detected in the first. The study I saw showed a 3:1 difference in  
compression ratio, so even with double sending the data, H.264 would  
be more efficient than JPEG2000 at a given quality level.

The other reason given for using JPEG2000 is that compression  
artifacts look more natural. But this is only if the scenes are  
natural and not text/graphics and you are at very high compression  
ratios.

Neil
On Dec 19, 2007, at 1:12 PM, Loren Merritt wrote:

> On Thu, 29 Nov 2007, List, Peter wrote:
>
>> As far as I know, one of the reasons for DCI to decide for JPEG2000  
>> and
>> against H.264 was the inability of H.264 to produce COMPLETELY
>> transparent quality at low compression rates at that time. Because of
>> that phenomena the gains of temporal prediction in H.264 were to a  
>> large
>> extend eaten up by the necessity to reduce qp more than expected to  
>> gain
>> the same visual quality than JPEG2000.
>
> That surprises me. In my experience, any intra codec (including  
> jpeg2k)
> requires lower quantizer than any inter codec (including h264 main
> profile) for a given perceptual quality. Because intra artifacts are
> temporally incoherent. A near-static region of the video becomes
> non-static when consecutive I-frames are quantized differently,  
> which is
> far more visible than any dct or wavelet artifact by itself.
>
> --Loren Merritt
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> http://mailman.videolan.org/listinfo/x264-devel