[FFmpeg-devel] [PATCH] Swscale - RGB48 to YUV conversion
Thu May 28 00:12:48 CEST 2009
On Wed, May 27, 2009 at 10:11:50PM +0300, Kostya wrote:
> On Wed, May 27, 2009 at 07:16:39PM +0200, Michael Niedermayer wrote:
> > On Wed, May 27, 2009 at 08:17:55AM +0300, Kostya wrote:
> > > On Tue, May 26, 2009 at 09:19:56PM +0200, Michael Niedermayer wrote:
> > > > On Tue, May 26, 2009 at 04:21:16PM +0300, Kostya wrote:
> > > > > On Tue, May 26, 2009 at 02:16:26PM +0200, Michael Niedermayer wrote:
> > > > > > On Tue, May 26, 2009 at 10:13:13AM +0300, Kostya wrote:
> > > > > > > $subj
> > > > > >
> > > > > [...]
> > > > > >
> > > > > > it would be nice if this wouldnt loose the 16bit per component
> > > > >
> > > > > Indeed. But I suspect that current scaler precision is rather low to
> > > > > accept all 16 bits of input data and not to lose them in process.
> > > >
> > > > The vertical scalers take more than 8 bit as input ...
> > >
> > > Maybe, but in general SwScaler is still designed for 8-bit input, isn't
> > > it? I can give more bits in this converter function but where they will
> > > be used and how to distinguish it from usual 8-bit input?
> > as said the vertical scalers have more than 8bit input, just change/extend
> > the horizontal scaler :)
> Small wish to support RGB48 by TIFF decoders seems to result in
> significant swscaler changes...
yes, iam not insisting on the 16bit hscaler stuff, your code is fine as
is as well. I just think a 16bit hscaler would be quite a "nice to have"
> > > BTW, this GSoC includes libswscale cleanup so you'd better give a clear
> > > list of what should be done there.
> > I think lists have been written already for previous swscale cleanups ...
> > but i dont mind at all to search these lists and check/extend them once our
> > student needs/wants them
> Well, IIRC you're the one who will accept/reject that work and last year
> attempt failed because student moved in wrong direction. Purely a
> selfish interest - the more somebody does on swscale the less is left to me.
i am happy about any advancement ...
Maybe you should talk to ramiro?
It really makes no difference to me if you implement the 16bit stuff or
ramiro, nor if that happens now or in a few month.
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No great genius has ever existed without some touch of madness. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel