[MPlayer-users] fb_dev: flickering output
Alexander Stein
alexander.stein at systec-electronic.com
Thu Mar 24 08:36:23 CET 2011
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.
> 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.
fbdev2 is not an option as I need the -geometry option. I need to scale my
video (currently 320x240) to something smaller than my display size (320x240).
I also added the possibility to support RGB15 on fbdev. I think I will send a
patch the next days.
> 3) a lot of fbdev drivers seem to be buggy with double-buffering, but if 2)
> does not help you I could look into it.
Well, I think i don't have to do much here currently, since I will eventually
run without double buffering (see above).
Regards,
Alexander
More information about the MPlayer-users
mailing list