[MPlayer-dev-eng] [PATCH] SUN XVR-100 VO driver 3. try

[Alban Bedel]

On Wed, 25 Jul 2007 23:35:46 +0200
Balatoni Denes <dbalatoni at interware.hu> wrote:

> Hi!
> 
> Wednesday 25 July 2007 22:56-kor Alban Bedel ezt írta:
> > > I did try it, it was much slower, so I didn't like it. Maybe in
> > > the future (btw it seems two vertical retraces are needed until
> > > the page is flipped, and that is slow).
> >
> > You don't have to vsync the flip, it's probably preferable, but not
> > requiered. However as Uoti pointed out you will need double buffer
> > for a proper timing.
> 
> It has to wait for the retrace, otherwise after flip_page mplayer
> starts rendering in the backbuffer, but it is still shown -> ugly
> artifact. Triple buffering would help, but I think I will just leave
> it for now.

I fear there is some misunderstanding here. So let's try to clear things
a bit, the basic flow in mplayer from the vo pov is:

1) The frame is decoded and passed to the vo
2) Sleep until it's time to show the new frame
3) Call flip to show the new frame

To do this with a typical overlay, you WILL need 2 buffer. One to
display the current frame and one to draw the new one, with flip()
switching the role of the 2. Anyway, this is really trivial to
implement, so I fail to see why you insist on keeping a totaly broken
behaviour instead.

> > > It works, but there is a pink stripe on the right side. So IMO the
> > > user should choose whether he/she wants pink stripe (-vo
> > > xover:xvr100) or unusably slow playback (-vo x11).
> >
> > Is the image scaled down or a part missing? If a part is missing I
> > would not consider that usefull and imho config() should fail. But
> > if it's scaled down, you could compute the effective size and pass
> > it back to xover to allow it to correctly resize the window.
> 
> A part is missing. It is exactly as usefull as -vo x11 (have you seen
> hd video decoding + c scaler downscaling on an UltraSPARC - like a
> very very very slow slideshow). This is really my opinion, because
> changing config would be easy, but as I described, not wanted.

I see your point. However mplayer has a large user base, so we must be
carefull with such things to avoid getting too many useless complaints
and bug reports. I see 2 solutions:

1) Fail at config() and add an option to continue anyway.
2) Print a big fat warning and continue.

I would prefer 1), but in both case it should make it perfectly clear
that it's a hw limitation, don't complain, don't report it as a bug,
etc

> > > > What is not working exactly?
> > >
> > > -vfm ffmpeg -dr always says "stride changed" or something like
> > > that (I don't have the message at hand), and some frames are not
> > > shown.
> >
> > You probably hit this pb:
> > http://article.gmane.org/gmane.comp.video.mplayer.devel/1130
> > It's a limitation of lavc, if it work fine with TEMP buffers you
> > should enable it imho.
> 
> Ok, great, probably this was it. But how can I test this TEMP buffer
> thing?

With a filter, for ex. expand with the osd enabled or scale. With -v
the requested mpi types will be displayed.

	Albeu