[MPlayer-dev-eng] [PATCH] SUN XVR-100 VO driver 3. try
Balatoni Denes
dbalatoni at interware.hu
Thu Jul 26 23:58:52 CEST 2007
Hi!
Thursday 26 July 2007 17:45-kor Alban Bedel ezt írta:
> > > 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.
I understood. What I wrote is I think correct, still. You need
triple-buffering. Otherwise - to reiterate - after page flip mplayer starts
rendering to the backbuffer. But it is still visible (for two vertical
retraces), so there is an artifact. Then it's flipped (after two vertical
retraces) so there is another flicker.
I know it's easy to do triple buffering (as I said there was double buffering,
but I removed it because I didn't like it), but I have already spent enough
time with this stuff, so I think I will leave fixing this to another time,
not in the near future.
> > 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 went with 2. But I am afraid if every xvr-100 user started complaining, you
still wouldn't get too many emails (because of their low number, that is).
> > > 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.
Thanks, tried it, it works - also other samples worked without TEMP buffer. So
I enabled it.
> Albeu
bye
Denes
More information about the MPlayer-dev-eng
mailing list