[MPlayer-dev-eng] -geometry code and -vo fbdev broken

[Michael Niedermayer]

Hi

On Sunday 23 February 2003 17:34, Joey Parrish wrote:
> On Sun, Feb 23, 2003 at 04:07:27PM +0100, Michael Niedermayer wrote:
> > :(, IMHO vo's shouldnt do such conversion themselfs, instead the video
> > : filter
> >
> > layer should do it, but if ppl disagree then ill fix all the affected
> > vo's so that they use the swscaler internally for the conversion (the
> > yuv2rgb code uses the swscaler context now ...)
>
> vo_gif89a uses yuv2rgb internally because it benefits from slices, but
> has to output everything in rgb.  Rendering the slices rather than full
> frames gives a noticable speed improvement when ripping to gif.  Also,
> there is potential to code something a lot like slices into the output
> gif, which would save a lot of space through motion compression.
> vo_gif89a does not currently do this, but it could be added in the future.
> (If I get around to gif hacking again this semester.)
the video filter stuff should convert the format and feed the VOs with slices 
of the correct format so the most common case would be yv12 slices -> rgb?? 
slices -> vo, there is no speed loss, but the code is much cleaner, as the 
conversion code is kept outside of the vo code ...

>
> I vote that gif89a and other vo's that have similar needs should be
> fixed to use swscale.  (Which, without RTFS I don't know how to do.  I'm
> currently working on more cygwin issues/testing, but if the vo is still
> broken later tonight, I'll probably figure it out and send a patch.)
hmm, anyway, if u really want to add more hacks, then i would recommand at 
least that u simply implement a yuv2rgb() & yuv2rgb_init() which call the 
swscaler & use global variables, its the smallest change which would 
workaround the problem, rewriting the yuv2rgb hack to a swscale hack in all 
VOs is IMHO very stupid

[...]

Michael