[x264-devel] x264-devel Digest, Vol 19, Issue 23

Ram prasad ramprasad85 at gmail.com
Tue Apr 28 10:37:45 CEST 2009


Thank you Dark
To begin with i'll use a variable where ever 420 is assumed. so that i can
encode 444 also.
Now, is there any thing I need to modify in the decoder side.
If yes please direct to a good decoder.
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
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x264-devel/attachments/20090428/4273a2e8/attachment.htm>


More information about the x264-devel mailing list