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

[Ivan Kalvachev]

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.

The proper code should look like:
mpi->planes[1]+=(yoffset >> mpi->chroma_y_shift)*mpi->stride[1]+
  (xoffset >> mpi->chroma_x_shift);