[MPlayer-dev-eng] wishlist again
D Richard Felker III
dalias at aerifal.cx
Tue May 27 01:01:45 CEST 2003
On Mon, May 26, 2003 at 10:33:17PM +0200, Roberto Togni wrote:
> On 2003.05.26 02:58 Arpi wrote:
> >> > 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
> >> > auto. filter insertion logic in g1/g2's video path a lot simpler.
> >> Well, the last time you wished for an improvement to swscaler
> >> 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
> >codecs with palette (mayeb only 8bpp msvideo1/cinepak and gif are such
> 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
> 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...
More information about the MPlayer-dev-eng