[x264-devel] Lossless H.264 encoding (8 bit grayscale video)

[Ram prasad]

Thank you for the response.As i had mentioned I am try to compress RGB 24
bit VGA video.
My input has mainly grayscale data and very little color information.
I have succeeded in separating the two. now i have an 8 bit grayscale video
(and *r*e*s*i*d*u*e*).
The previous reply had the steps to make x264 work with yuv 420. Thank you
very much for that.
Before i start with that i feel if x264 works with YUV 4:0:0, it can be used
to compress 8-bit video.
I also think if this feature is 'added' to x264, it will be become possible
to use it in many other useful ways easily.
Can you kindly tell me the steps to make x264 accept YUV 4:0:0.
Thank you


On Tue, Dec 23, 2008 at 4:30 PM, <x264-devel-request at videolan.org> wrote:

> Send x264-devel mailing list submissions to
>        x264-devel at videolan.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://mailman.videolan.org/listinfo/x264-devel
> or, via email, send a message with subject or body 'help' to
>        x264-devel-request at videolan.org
>
> You can reach the person managing the list at
>        x264-devel-owner at videolan.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of x264-devel digest..."
>
>
> Today's Topics:
>
>   1. Lossless H.264 encoding (Ram prasad)
>   2. Re: Lossless H.264 encoding (Jason Garrett-Glaser)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 23 Dec 2008 15:26:14 +0530
> From: "Ram prasad" <ramprasad85 at gmail.com>
> Subject: [x264-devel] Lossless H.264 encoding
> To: x264-devel at videolan.org
> Message-ID:
>        <aeec8fa30812230156q19690a01l70b257b780d4708b at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi allMy source data is raw 24 bit RGB VGA video. I want to encode it into
> a
> h.264 video. my requirement is that this should be a lossless compression.
> Looking at the code i think x264 does not support any other format other
> than YUV 420. I am planning to modify the code to make it work on high
> quality YUV 444 or if possible on the RGB data itself.
> Before i embark on this task i would like to know whether it is feasible or
> not. if it is yes, how much effort would it require.
> Please share your thoughts.
> Thank you
>
> Regards
> Ramprasad N
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://mailman.videolan.org/pipermail/x264-devel/attachments/20081223/3e6a562f/attachment.html
>
> ------------------------------
>
> Message: 2
> Date: Tue, 23 Dec 2008 05:05:24 -0500
> From: "Jason Garrett-Glaser" <darkshikari at gmail.com>
> Subject: Re: [x264-devel] Lossless H.264 encoding
> To: "Mailing list for x264 developers" <x264-devel at videolan.org>
> Message-ID:
>        <28f2fcbc0812230205n34b49c18h74190fbca69b4ffa at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> 2008/12/23 Ram prasad <ramprasad85 at gmail.com>:
> > Hi all
> > My source data is raw 24 bit RGB VGA video. I want to encode it into a
> h.264
> > video. my requirement is that this should be a lossless compression.
> Looking
> > at the code i think x264 does not support any other format other than YUV
> > 420. I am planning to modify the code to make it work on high quality YUV
> > 444 or if possible on the RGB data itself.
> > Before i embark on this task i would like to know whether it is feasible
> or
> > not. if it is yes, how much effort would it require.
>
> RGB support is probably not feasible; I don't even know if the spec
> supports it, and even if it does, I know of no decoders that do--you'd
> have to modify a decoder to support it to, and you'd probably end up
> having to use the Separate Chroma Plane coding feature, where each
> chroma plane is its own image.
>
> YUV444 is definitely feasible.  It would require the following changes:
>
> 1.  In all cases where chroma planes are handled, instead of >>1 to
> get the size of chroma, or chroma stride, or whatever, a variable
> would have to be used.  This is probably the most time consuming step
> by far--going through all the code, finding all places where 420 is
> assumed, and fix it.
> 2.  AFAIK, a different Hadamard transform is used for chroma coding
> for 422/444.  This isn't important in lossless mode, but it would have
> to be implemented for the feature to be accepted (since lossy is also
> useful...).  It probably wouldn't be much work though.  In fact, if
> I'm right, you might be able to just use the luma transform for chroma
> in 444, as I think they might be the same.
> 3.  Deblock would have to be called on more chroma edges accordingly.
> Not important in lossless, but would be needed for lossy.
> 4.  Increase the size of the necessary dct blocks in x264_t to add
> enough room for all the chroma DCTs and adjust CABAC/CAVLC coding as
> necessary.
>
> Dark Shikari
>
>
> ------------------------------
>
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> http://mailman.videolan.org/listinfo/x264-devel
>
>
> End of x264-devel Digest, Vol 19, Issue 23
> ******************************************
>



-- 
"Love all serve all" - ..::Sri Sathya Sai::..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.videolan.org/pipermail/x264-devel/attachments/20081229/c99220c4/attachment.htm