[x264-devel] I444 support
Neil Woodall
vidsurfr at gmail.com
Tue Jan 15 05:39:32 CET 2008
One thing to consider is that for DCI application you are likely
digitizing at a resolution greater than the film grain. In that
application, JPEG-2000 might actually do better.
You should also check out the following website for some comparisons:
http://compression.ru/video/codec_comparison/index_en.html
On Jan 14, 2008, at 8:28 PM, James Gardiner wrote:
> Thank you the clarification Neil,
> It is just that I had not considered or heard about M-JPG2000 being
> used
> as a transmition/streaming codec.
>
> I am mainly interested in H.264 as a hi-quality distribution codec for
> cinema type application that is an alternative to DCI (JPEG2000).
> H.264 High Profile 4:4:4 (With 10/12 bit support and up to 4k
> resolution) sounds like a good alternative with some advanyages over
> JPEG2000, mainly being high precevible quality and colour depth at
> much
> lower bitrates.
>
> Reading comments from the list, it appear that this is the general
> conclusion. Still, I would be interested in knowing exactly how much
> better the compression would be for H.264 over JPEG2000. I expect I
> will not find out until I get my hands on an H.264 implementation that
> supports it.
>
> Currently I know of two different companies working on releasing this
> feature before 1st half this year.
>
> Thanks,
> James
>
>
>
> -----Original Message-----
> From: x264-devel-bounces at videolan.org
> [mailto:x264-devel-bounces at videolan.org] On Behalf Of Neil Woodall
> Sent: Tuesday, 15 January 2008 11:00 AM
> To: Mailing list for x264 developers
> Subject: Re: [x264-devel] I444 support
>
> Transmission errors would be corruption of data. In a broadcast mode
> it would not always be possible to ask the source to resend the data.
>
> H.264 has a series of mechanisms to improve error resiliency. One of
> the methods is to include redundant picture frames and with redundant
> slices. Another would be to simply force a larger amount of the blocks
> to be intra coded.
>
> The point that I was trying to make is that if you have enough
> bandwidth for M-JPEG2000, then you probably have enough bandwidth to
> make sure that the H.264 is more resilient to errors than is normally
> the case.
>
>
> On Jan 14, 2008, at 2:03 PM, James Gardiner wrote:
>
>>
>> Can you please qualify,
>> On this topic of 444 and quality compared to JPEG2000.
>> Can you be more clear on what " transmission errors are"?
>> I took them to mean in accuracies compared to the original.
>> Then in other posts, it leads me to think you are talking about
>> Real transmission errors as in what is characteristic of DVB-T or
>> satellite.
>>
>> However, I am not sure how "transmitting them twice" actually means
>> considering this.
>>
>> If you have time to clarify, this would be appreciated.
>>
>> James
>> _______________________________________________
>> x264-devel mailing list
>> x264-devel at videolan.org
>> http://mailman.videolan.org/listinfo/x264-devel
>
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> http://mailman.videolan.org/listinfo/x264-devel
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> http://mailman.videolan.org/listinfo/x264-devel
More information about the x264-devel
mailing list