[MPlayer-dev-eng] [PATCH] VF Overlay

[Uoti Urpala]

On Tue, 2009-09-22 at 15:07 -0400, Jason Tackaberry wrote:
> On Tue, 2009-09-22 at 21:41 +0300, Uoti Urpala wrote:
> > Now the pause hacks have been removed, which makes the patch less
> > actively harmful in the sense that it can be ignored or easily deleted
> > later without affecting anything else; but OTOH that makes its
> > deficiency as an overlay implementation more apparent than ever. I
> > wouldn't want any frontends to start relying on it. IMO the included
> 
> Front-ends are already using vf_bmovl.  vf_overlay is a lot nicer for
> front-ends, so can't it be pitched as a better bmovl?

Maybe. It should still be clear that any such use is discouraged.

> > least there should be clear warnings that this functionality is not
> > supported, may arbitrarily fail depending on other settings,
> 
> Refresh my memory: what other settings may cause it to arbitrarily fail?

I think the most obvious problems people would see occur with VDPAU.
This approach obviously fails completely with hardware decoding. Result
with deinterlace will at least be suboptimal even if doing the decoding
in software (especially significant for TV frontends). And it looks like
some additional frame buffering is beneficial with VDPAU, emphasizing
that the filter chain is not suited to realtime-related modifications.

> > and may be completely disabled or removed at any time.
> 
> Can the same be said about vf_bmovl, and if not, why not?

I think it can at least be said that bmovl may not work as its users
wish in a future default configuration of MPlayer, and getting it to
work even at the level it does now would require disabling features most
MPlayer users won't want to disable.