[MPlayer-dev-eng] Re: [PATCH] VFCTRL_PERIODIC_UPDATE

[Michael Niedermayer]

Hi

On Wed, Jan 24, 2007 at 12:52:42AM +0200, Uoti Urpala wrote:
> On Tue, 2007-01-23 at 21:57 +0100, Michael Niedermayer wrote:
> > On Tue, Jan 23, 2007 at 05:04:20PM +0200, Uoti Urpala wrote:
> > > On Tue, 2007-01-23 at 08:39 -0500, Jason Tackaberry wrote:
> > > > Right, being vo-independent is a requirement.  
> > > 
> > > A requirement for what? If you were willing to require -nodouble then
> > > requiring a particular vo (or one of a few alternatives) should be minor
> > > in comparison...
> > 
> > i very strongly vote for a vo-independent solution (=one which works with
> > all VOs)
> 
> Are you sure you understand what you're voting about? Almost everything
> in this whole thread is about features to support updating the overlay
> more often than once per frame; parts of your post sound like you might
> have missed that. 

well there are 2 possibilities either frame insertion filters (like tfields)
currently work with mplayer or they dont
if they do then the overlay filter is not affected by the time between input
frames, it can just add more frames if the overlay chages
OTOH if such filters are broken, they should be fixed first


> Or perhaps you omitted too much of exactly what you
> mean by "a vo-independent solution".

i think "one which works with all VOs" is clear


[...]
> > i also would like to point at the fact that these VO buffers may not be
> > readable (=insanely slow due to the hw not being designed for reading)
> > which would make a blend in VO memory a hopelessly stupid idea
> 
> I'm perfectly aware that some VOs might require caching the image
> separately to allow updating it. However I don't think that is normally
> the case with xv for example, and the non-ass subtitle/OSD code already
> does blending in VO memory in some VOs. Do you think the existing OSD
> code is "hopelessly stupid"? I haven't heard complaints about its
> performance.

iam not against optionally handling the overlay at VO level, there are
cases where this could be better (if the hardware can do the blending for
example)
but there should be a fallback if the VO does not support it and that
fallback is whats needed first (optimization at VO level can be done 
later ...)

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20070124/db18101d/attachment.pgp>