[MPlayer-users] fb_dev: flickering output
Reimar Döffinger
Reimar.Doeffinger at gmx.de
Thu Mar 24 19:05:52 CET 2011
On Thu, Mar 24, 2011 at 08:36:23AM +0100, Alexander Stein wrote:
> On Wednesday 23 March 2011, 21:15:43 Reimar Döffinger wrote:
> > On Wed, Mar 23, 2011 at 01:51:08PM +0100, Alexander Stein wrote:
> > > On Tuesday 22 March 2011, 21:11:27 Carl Eugen Hoyos wrote:
> > > > Alexander Stein <alexander.stein <at> systec-electronic.com> writes:
> > > > > I tried rc4 and noticed a slight flicking in the output. Especially
> > > > > if i fill the framebuffer using cat /dev/urandom > /dev/fb0.
> > > > > Using rc2 there is no such flickering. I tried to bisect the problem,
> > > > > but I have problem building mplayer.
> > > >
> > > > svn co -r {2010-09-27} svn://svn.ffmpeg.org/mplayer/trunk mplayer
> > > > cd mplayer
> > > > svn up --ignore-externals -r {2010-09-27} libavutil/ libavformat/
> > > > libavcodec/ libavcore/ libpostproc/ libdvdread4/ libdvdnav/
> > > > ./configure && make
> > > > make distclean
> > > > svn up --ignore-externals -r {2009-12-31}
> > > > svn up --ignore-externals -r {2009-12-31} libavutil/ libavformat/
> > > > libavcodec/ libpostproc/ libdvdread4/ libdvdnav/
> > > > ./configure && make
> > > >
> > > > Note that libavcore was introduced around 2010-07-21, do not add it to
> > > > earlier update commands!
> > > >
> > > > I don't know if it is possible to test versions after 2010-09-26.
> > >
> > > Thanks a lot. This helped me tracking down the problem to be caused by
> > > double buffering. Disabling it I get nice output, like in rc2.
> > > Nevertheless I don't know if there problem is my hardware (AT91SAM9263)
> > > or the driver atmel_lcdfb but that's an other area.
> >
> > You didn't give enough information, however there are several things to not
> > 1) disabling double-buffer in my experience results in horrible tearing
>
> Can you elaborate a bit? Disabling double buffering seem to do what I want
> without interfering the rest of the screen.
It causes horribly annoying (nearly) horizontal lines.
This is caused by the top half being the next frame while the lower half
is the bottom frame.
> > 2) double-buffering uses two different parts of memory in sequence.
> > In "windowed" mode MPlayer on purpose does not clear the screen (so you
> > can e.g. have a video playing "on top" of your terminal), so if you fill
> > it with random data the background will flip between completely
> > different things there. -fs should help, at least for fbdev2.
>
> Yep, after knowing this is double buffering related, the effect is reasonable.
> Well, I have to disable double buffering, since we want to use another app
> which draws on the framebuffer and doesn't touch a 'window rect' where mplayer
> should draw.
You don't have to disable double-buffer you could just make that other app draw
into both buffers.
> I also added the possibility to support RGB15 on fbdev. I think I will send a
> patch the next days.
Did the patch I sent not work?
More information about the MPlayer-users
mailing list