[mythtv] [mythtv-commits] mythtv commit: r14461 by nigel

Daniel Kristjansson danielk at cuymedia.net
Mon Sep 10 13:31:59 UTC 2007

On Mon, 2007-09-10 at 13:04 +1000, Nigel Pearson wrote:
> >> Re-allow compile after [14435]. Sadly, the aspect changing is  
> >> still broken.
> >
> > Nigel, I started working on this but got hopelessly lost in all the
> > Quartz views.
> Yes. That code was a "Jeremiah special."
> Actually very tidy for what it does,
> but not for the faint hearted :-)

:) The code is not so bad, it's the underlying VideoOutput
which has caught up with and surpassed the views code, and
the views code simply hasn't benefited from the improvements
in the base class...

> > We should really just take the output of
> > MoveResize() and convert it into matrix form.
> Good thought, but I'm not sure that will work with the
> different views' varying aspects (e.g. Dock Icon is square).

Yeah, my thinking is that we would either only do this for the main
view, or alternatively rework VideoOutput to allow for multiple views;
MoveResize and it's helper methods are already fairly modular.

> (but that is a problem for after the DVDV OpenGL crashes.)

Merging the different OpenGL renderers is definately first.
DVDV OpenGL is very similar to XvMC OpenGL, neither of which
is taking advantage of the cool new features in the Kendall's
Regular OpenGL Video Renderer. I also want to share the context
with OpenGL V-Sync when it is being used, to avoid the context
switch for V-Sync. And I also want to fix OpenGL V-Sync locking,
it uses an unprotected by X11S() glX call. Using an X11 lock
for it would eliminate a lot of segfaults, but currently we
spend too much time in there so if we apply the lock we end
up not being able to decode video fast enough; we need to wait
using another method first and only enter the glX vsync call
just before we expect the vsync to happen. While we're at it
we might also want to make the OpenGL V-Sync top and bottom
field aware...

> P.S. Do you have any thoughts about the Mac-only
> setting "Scale Video as necessary"?
> Jer and I added this ages ago, for very-low-end HW
> that was scaling up in software. (e.g. non-XV)
> We always meant to move it into the base class.

I dunno, for the other video renderers we've been using snapping
for a while now to avoid unneeded scaling. But OSX doesn't benefit
from this is because it doesn't use the output of MoveResize()...

> With software scaling probably being added in the future,
> should the playback profiles have a Scaling selector, too?
> e.g. None, Hardware, libSWscale

Yeah, but we have to write these scalers first...

-- Daniel

More information about the mythtv-dev mailing list