[MPlayer-dev-eng] wishlist again

[D Richard Felker III]

On Mon, May 26, 2003 at 10:33:17PM +0200, Roberto Togni wrote:
> On 2003.05.26 02:58 Arpi wrote:
> >Hi,
> >
> >>  > yes, it would be nice, but now very useless (who needs qt dll's
> >svq1 decoder
> >>  > now... and it's the only user of syuv format)
> >>  >
> >>  > and paletted rgb support too, it could obsolete vf_palette and
> >make
> >>  > auto. filter insertion logic in g1/g2's video path a lot simpler.
> >>
> >> Well, the last time you wished for an improvement to swscaler
> >Michael
> >> implemented it by the next day.  Maybe you are lucky again ;-)
> >
> >no, i've requested this one already several times :)
> >but i accept that it's quite low priority and nearly nobody actually
> >uses
> >codecs with palette (mayeb only 8bpp msvideo1/cinepak and gif are such
> >things)
> If everyone agree, we could change the codecs to output something 
> non-palettized like BGR15 or BGR16, or even BGR24/32 to have a lossless 
> conversion.
> IIRC all palettized codec are available also as native codecs (msv1, 
> cinepak, qtrle, msrle, fli, smc, gif, ...). Do you know of any 
> binary-only decoder that only has palettized output?
> The only bad side of this solution is that dithering is required if you 
> use a palettized vo, while now it can be avoided.

No, this is dumb, for 2 reasons:

1, it's ugly -- duplicating conversion code in all the codecs rather
than just once in vf_scale.

2, it's slow!!! If the vo can display palette-based video, it's much
faster just to support that. But also, palletized rgb8->yuv conversion
is a LOT faster than rgb8->rgb24->yuv!!! (Just convert the palette,
not every pixel!) Each codec could individually handle yuv output, but
this would be even more ugly bloat where it doesn't belong...


Rich