[MPlayer-cvslog] r24966 - trunk/libvo/vo_directfb2.c

[Ville Syrjälä]

On Mon, Nov 05, 2007 at 05:20:28PM +0200, Ivan Kalvachev wrote:
> 2007/11/5, Reimar Döffinger <Reimar.Doeffinger at stud.uni-karlsruhe.de>:
> > Hello,
> > On Mon, Nov 05, 2007 at 02:14:02PM +0000, Carl Eugen Hoyos wrote:
> > > Ivan Kalvachev <ikalvachev <at> gmail.com> writes:
> > >
> > > > Wrong colors is exactly what the bug should cause.
> > > > To trigger it you must have xoffset !=0 , this means image with
> > > > smaller width than the framebuffer.
> > >
> > > I found out how to use directfb: I had to add -vf format=bgr16 (how do I choose
> > > another surface?), however, using a video with smaller width than framebuffer
> > > (320 vs 640) I saw no difference before the patch and after, with -dr and
> > > without. I could only try with buffermode=single and buffermode=triple, double
> > > still shows a black image for me.
> >
> > I am rather sure that code is for YV12 framebuffer, I am almost certain
> > nobody with standard PC hardware has such a thing.
> 
> Not only it depends on yv12 framebuffer, it also requires on set of
> (not) supported capabilities. This probably explains why it haven't
> been noticed so far.
> 
> The code in question is used only for yv12, and when temp buffer
> (!frame) is not used. The frame temp buffer allocation is conditioned
> at line 839. It would require setting flip mode for the vo (and
> vf_flip usually kicks in for yv12, also dfb have its own set of
> flipping capabilities), or having stretch mode (aka not supported
> hardware scale).
> Have in mind that you also need x/y_offset >0.
> 
> So to trigger the bug in addition to the yv12, you may also need to
> forge param.scale before the check in line 620.

You can get a YV12 framebuffer with DirectFB + Matrox G400/G450/G550
hooked up to a TV. Then if you disable acceleration and watch a video
smaller than the native TV resolution you might hit this codepath.

-- 
Ville Syrjälä
syrjala at sci.fi
http://www.sci.fi/~syrjala/