[FFmpeg-devel] [PATCH] Swscale - RGB48 to YUV conversion
Wed May 27 21:11:50 CEST 2009
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...
> > 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.
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
More information about the ffmpeg-devel