Mailing List Archive: MythTV: Dev

MythUI OSD branch and the way forward

1 2

View All

Index | Next | Previous | View Threaded

mark.kendall at gmail

Mar 22, 2010, 9:04 PM

Post #1 of 34 (3834 views)
Permalink

MythUI OSD branch and the way forward

Morning All,

There has been some discussion on irc recently regarding the
libmythui-osd branch and how to support XVideo (and XvMC) going
forward. It's not a straightforward issue and any resolution is likely
to have wider implications - so it's about time I tried explaining it
in a little more detail and the options I believe we have. Apologies
if some of the following is teaching some (or all!) of you to suck
eggs.

- Background

The aim of the branch is to draw the OSD using the libmythui-code.
This gives users a consistent look and feel, gives themers
significantly more opportunity to theme the osd (and a consistent
theme format) and should allow us to remove significant amounts of OSD
code. Ideally a win/win/win.

My longer term aims have always been broader. By combining the
rendering code for the UI and video, I'm targetting a situation in
which video is just another UI widget to be toyed with by themers and
normal video playback is a just a fullscreen widget. Picture In
Picture might become just another OSD UI widget and with some
modifications to NuppelVideoPlayer it can become a generic media
player (i.e. music and video) with visualisations built in. I guess
the extreme case is where the media becomes the background (whether it
is livetv, music visualiser, album photo etc) and the UI is alpha
blended on top.

While admittedly it's all just eye candy, I'd like to think that most
people would think it's a good thing! (and for what it's worth, it's
probably not that far away)

- The Problem

All of the above is, in general, pretty straightforward when using
OpenGL or Direct3D for the video and the UI. So probably no issue on
either Windows or Mac (both of which will also have useable hardware
drivers and most users will have sufficiently powerful GPUs).

On linux VDPAU will handle the rendering basics well enough but in the
future we may want to use OpenGL rendering directly. Any VDPAU capable
card also has sufficient OpenGL horsepower.

Very little of this will work well with XVideo however (XvMC is even
worse) (and in certain situations the hardware drivers just aren't
good enough to give the OpenGL performance we need on linux).

There are essentially three problems with XVideo:-

- XVideo handles video only (or more precisely images in the YUV
colorspace and by and large planar formats), there is no API to
manipulate the images after they have been converted/scaled and there
is no way of reliably and consistently integrating them with other
hardware acceleration APIs.

- we by default rely on creating a YUV osd image which is then
blended into the video frame (in software). This image will usually be
a different size to the main UI. As a result we either need to use OSD
specific theme elements or reload/resize the main UI.
(OpenGL/VDPAU/Direct3D all create the OSD at the screen resolution
which should match the UI size - although there will be exceptions
that need to be handled)

- blending in software is not cheap and as the OSD becomes larger and
more complicated, there is a significant performance hit. For example,
a number of the newer themes use popups with essentially a fullscreen
alphamask (to darken the background) - this is simply not going to
work when trying to play h264 1080 material.

- Options

There are 1001 possible workarounds, hacks and solutions and I've
listed a few options below. I do however feel it's worth pointing out
that any long term solution that includes support for XVideo will be a
compromise for the rest of the UI and hence the rest of the
application.

Option 1 - Do nothing

i.e. do not merge in the branch when complete.

Option 2 - Provide XVideo (and XvMC?) OSD support only via Chromakeying.

The Chromakey OSD operates at the screen resolution and rendering on
screen is not as expensive as the software blend. I think the XVideo
chromakey was dropped by Nvidia for 7xxx series cards and later and is
by and large still available on Intel. Although i don't know about
ATI, this may be a useful short term option for users of 'legacy'
cards (but many of the longer term UI features will not be doable).

Option 3 - Use specific 'legacy' OSD themes for XVideo to avoid the
sizing issue.

Far from ideal from a themers perspective and does not provide a long
term solution.

Option 4 - Force resizing of the main UI when needed.

This is going to be extremely expensive and may simply not be doable
in certain situations (e.g. guidegrid during playback). XVideo
blending will still be expensive and still no future improvements.

Option 5 - Force an XVideo overlay

On systems without chromakey support, try and render the OSD directly
on top of the video frame using the Qt X11 pixmaps directly. I have no
idea whether this will work (it is impossible to test until some
threading issues have been resolved), though I think there will be
blending/compositing issues. Regardless - it will be ugly! There may
also be a solution here involving the X composite extension but given
we are trying to support older hardware...

Option 6 - Drop XVideo/XvMC support and standardise around OpenGL

There are numerous ways of approaching this but I would clean up the
current OpenGL video code, standardise around GLSL for shader support
(UI effects, deinterlacing, colorspace conversion), remove OpenGL code
based around immediate mode (for OpenGL ES compatability), provide
colourspace conversion only support for ARB_fragment_program (for
older OpenGL implementations which will probably not be capable of
using any advanced video shaders anyway) and use OpenGL as the
'frontend' for VDPAU.

It's probably worth dropping Direct3D support as it offers nothing
above and beyond OpenGL and simply represents duplicated code (esp.
around supporting HLSL).

There is then also a separate debate to be had around the Qt painter....

Option 6 - Drop support in stages

Move to Option 2 for the 0.24 release and Option 6 for 0.25.

Option 7 - Maintain a legacy branch

Cut a stable 'Legacy' branch with XVideo support and move to Option 6
for 0.24 (assuming it's ready). Provide X weeks/months/years of legacy
support...

Hopefully that's all sufficiently clear. If not, I'll crawl back into
my hole and brood on it some more:) In case it isn't obvious, I'd like
to move to option 6 as soon as possible - but it's not my decision and
I've spent so long working on it that I may have overlooked the
obvious...

Regards

Mark

PS Nigel - I've deliberately not mentioned OS X quartz/accelerated
support - mostly because I still can't get trunk to compile on Snow
Leopard. I do feel however that OS X support should probably be based
around OpenGL regardless to maintain consistency across platforms.

PPS I've almost finished converting the last of the video code to
using the mythui osd. After that the threading in video playback needs
to be changed signicantly. This will involve sizeable changes to
NuppelVideoPlayer and will take some time. With a fair wind, I'm
hoping that we could consider a merge in around 3-4 weeks time.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

robert.mcnamara at gmail

Mar 22, 2010, 9:14 PM

Post #2 of 34 (3767 views)
Permalink

Re: MythUI OSD branch and the way forward [In reply to]

On Mon, Mar 22, 2010 at 9:04 PM, Mark Kendall <mark.kendall [at] gmail> wrote:

> Hopefully that's all sufficiently clear. If not, I'll crawl back into
> my hole and brood on it some more:) In case it isn't obvious, I'd like
> to move to option 6 as soon as possible - but it's not my decision and
> I've spent so long working on it that I may have overlooked the
> obvious...

Mark,

I am all for your approach of option 6. I don't know if this will
ease any tensions or confusions that might arise in reading this, but
some of the arguments for this approach in my mind are:

* It allows for some extremely fancy UI integration with video,
unlocking potential UI capabilities people have often wished for in
Myth.
* It is the same approach that is used across a wide variety of
hardware by XBMC and Boxee, which also do their rendering in GL.
* Simpler maintenance of the video output code.

The work you have done on the OSD branch is enormous and In my
(admittedly biased) opinion, I think that it's better to "measure
twice and cut once" as my mother would say-- do it right the first
time. Thanks for all you done, I say "go for it."

Robert
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

robert.mcnamara at gmail

Mar 22, 2010, 9:25 PM

Post #3 of 34 (3768 views)
Permalink

Re: MythUI OSD branch and the way forward [In reply to]

On Mon, Mar 22, 2010 at 9:04 PM, Mark Kendall <mark.kendall [at] gmail> wrote:
> Option 6 - Drop XVideo/XvMC support and standardise around OpenGL
>
> There are numerous ways of approaching this but I would clean up the
> current OpenGL video code, standardise around GLSL for shader support
> (UI effects, deinterlacing, colorspace conversion), remove OpenGL code
> based around immediate mode (for OpenGL ES compatability), provide
> colourspace conversion only support for ARB_fragment_program (for
> older OpenGL implementations which will probably not be capable of
> using any advanced video shaders anyway) and use OpenGL as the
> 'frontend' for VDPAU.
>
> It's probably worth dropping Direct3D support as it offers nothing
> above and beyond OpenGL and simply represents duplicated code (esp.
> around supporting HLSL).
>
> There is then also a separate debate to be had around the Qt painter....
>
> Option 6 - Drop support in stages
>
> Move to Option 2 for the 0.24 release and Option 6 for 0.25.
>

For reference, I really really like the first Option 6, but could live
with the second option 6 in a pinch. ;)

Robert
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

gjhurlbu at gmail

Mar 22, 2010, 9:29 PM

Post #4 of 34 (3775 views)
Permalink

Re: MythUI OSD branch and the way forward [In reply to]

On Tue, Mar 23, 2010 at 12:04 AM, Mark Kendall <mark.kendall [at] gmail> wrote:
> Option 6 - Drop XVideo/XvMC support and standardise around OpenGL
>
> There are numerous ways of approaching this but I would clean up the
> current OpenGL video code, standardise around GLSL for shader support
> (UI effects, deinterlacing, colorspace conversion), remove OpenGL code
> based around immediate mode (for OpenGL ES compatability), provide
> colourspace conversion only support for ARB_fragment_program (for
> older OpenGL implementations which will probably not be capable of
> using any advanced video shaders anyway) and use OpenGL as the
> 'frontend' for VDPAU.
>
> It's probably worth dropping Direct3D support as it offers nothing
> above and beyond OpenGL and simply represents duplicated code (esp.
> around supporting HLSL).
>
> There is then also a separate debate to be had around the Qt painter....
>
> Option 6 - Drop support in stages
>
> Move to Option 2 for the 0.24 release and Option 6 for 0.25.
>
> Option 7 - Maintain a legacy branch
>
> Cut a stable 'Legacy' branch with XVideo support and move to Option 6
> for 0.24 (assuming it's ready). Provide X weeks/months/years of legacy
> support...

OK, I'm confused.. which Option 6 above were you planning on going forward with?

I'd like to put in a short word for support for VA API in your first
Option 6, whether above or below VDPAU. This will give support to
several other chipsets, including the dreaded GMA500 that is in so
many tiny Atom boxes. I have one here that I hope to get the frontend
code working with sometime after 0.23. Obviously, I'd like to work
with whoever is necessary to make this happen, but I'm willing to do a
bunch of the heavy lifting on that. I don't want to break your work,
of course :)

OpenGL does sound like a good methodology to me.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

mtdean at thirdcontact

Mar 22, 2010, 9:30 PM

Post #5 of 34 (3773 views)
Permalink

Re: MythUI OSD branch and the way forward [In reply to]

On 03/23/2010 12:14 AM, Robert McNamara wrote:
> On Mon, Mar 22, 2010 at 9:04 PM, Mark Kendall wrote:
>
>> Hopefully that's all sufficiently clear. If not, I'll crawl back into
>> my hole and brood on it some more:) In case it isn't obvious, I'd like
>> to move to option 6 as soon as possible - but it's not my decision and
>> I've spent so long working on it that I may have overlooked the
>> obvious...
>>
> I am all for your approach of option 6. I don't know if this will
> ease any tensions or confusions that might arise in reading this, but
> some of the arguments for this approach in my mind are:
>
> * It allows for some extremely fancy UI integration with video,
> unlocking potential UI capabilities people have often wished for in
> Myth.
> * It is the same approach that is used across a wide variety of
> hardware by XBMC and Boxee, which also do their rendering in GL.
> * Simpler maintenance of the video output code.
>
> The work you have done on the OSD branch is enormous and In my
> (admittedly biased) opinion, I think that it's better to "measure
> twice and cut once" as my mother would say-- do it right the first
> time. Thanks for all you done, I say "go for it."
>

Agreed. I like option 6--ideally, the first option 6 you mentioned
("Option 6 - Drop XVideo/XvMC support and standardise around OpenGL,"
and not the second, "Option 6 - Drop support in stages" :).

Also--keeping in mind that I make no promises here (and am /definitely/
not making promises for Mark)--didn't I hear mention that the
OpenGL-only approach would likely be workable on all NVIDIA GF6x00 cards
and above? (Just to give readers an idea of what kind of hardware we're
talking about here--hardly top-of-the-line stuff.)

Mike
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

mrand at pobox

Mar 23, 2010, 7:17 AM

Post #6 of 34 (3737 views)
Permalink

Re: MythUI OSD branch and the way forward [In reply to]

On Mon, Mar 22, 2010 at 11:30 PM, Michael T. Dean
<mtdean [at] thirdcontact> wrote:
> On 03/23/2010 12:14 AM, Robert McNamara wrote:
>>
>> On Mon, Mar 22, 2010 at 9:04 PM, Mark Kendall wrote:
>>
>>>
>>> Hopefully that's all sufficiently clear. If not, I'll crawl back into
>>> my hole and brood on it some more:) In case it isn't obvious, I'd like
>>> to move to option 6 as soon as possible - but it's not my decision and
>>> I've spent so long working on it that I may have overlooked the
>>> obvious...
>>>
>>
>> I am all for your approach of option 6. �I don't know if this will
>> ease any tensions or confusions that might arise in reading this, but
>> some of the arguments for this approach in my mind are:
>>
>> * It allows for some extremely fancy UI integration with video,
>> unlocking potential UI capabilities people have often wished for in
>> Myth.
>> * It is the same approach that is used across a wide variety of
>> hardware by XBMC and Boxee, which also do their rendering in GL.
>> * Simpler maintenance of the video output code.
>>
>> The work you have done on the OSD branch is enormous and In my
>> (admittedly biased) opinion, I think that it's better to "measure
>> twice and cut once" as my mother would say-- do it right the first
>> time. �Thanks for all you done, I say "go for it."
>>
>
> Agreed. �I like option 6--ideally, the first option 6 you mentioned ("Option
> 6 - Drop XVideo/XvMC support and standardise around OpenGL," and not the
> second, "Option 6 - Drop support in stages" :).
>
> Also--keeping in mind that I make no promises here (and am /definitely/ not
> making promises for Mark)--didn't I hear mention that the OpenGL-only
> approach would likely be workable on all NVIDIA GF6x00 cards and above?
> �(Just to give readers an idea of what kind of hardware we're talking about
> here--hardly top-of-the-line stuff.)

In principle, I agree with option 6 as well. Mike's question hints at
my single question regarding the topic though: does option 6 (first
one) mean that pretty much everyone must have video acceleration
hardware (or else a fairly powerful CPU)? Or can the thousands of
users that currently use mpeg-2 encoders and have standard-def analog
TVs likely continue with their current hardware (assuming their
current hardware handles the heavier themes in 0.23)?

Marc
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

danielk at cuymedia

Mar 23, 2010, 7:23 AM

Post #7 of 34 (3741 views)
Permalink

Re: MythUI OSD branch and the way forward [In reply to]

On Tue, 2010-03-23 at 12:04 +0800, Mark Kendall wrote:

> Option 6 - Drop XVideo/XvMC support and standardise around OpenGL

I wrote much of the current code for XVideo and XvMC support, but I
think this is the way to go forward. My only significant concern is
that feature freeze for 0.24 is only a couple months away, will the
major issues be worked out before then? A secondary concern is that
we have a roadmap for supporting VAAPI. Does VAAPI allow us to turn
the decoded surfaces into OpenGL textures?

We should probably apply bug fixes more conscientiously to the last
XVideo supporting MythTV release, whether it is 0.23 or 0.24 as a number
of people will be stuck at that release for a while until they get
around to upgrading or replacing the older machines.

If we drop Qt painting we need to implement clipping in the GL
painter, running with the Qt painter is currently a very good
debugging tool when tweaking themes.

-- Daniel

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

ylee at pobox

Mar 23, 2010, 11:04 AM

Post #8 of 34 (3722 views)
Permalink

Re: MythUI OSD branch and the way forward [In reply to]

Mark Kendall <mark.kendall [at] gmail> says:
> There has been some discussion on irc recently regarding the
> libmythui-osd branch and how to support XVideo (and XvMC) going
> forward.

This is the branch that was at one point going to be merged into 0.23,
right?

> On linux VDPAU will handle the rendering basics well enough but in
> the future we may want to use OpenGL rendering directly. Any VDPAU
> capable card also has sufficient OpenGL horsepower.

I am displaying my ignorance here, but are you talking about someday
bypassing the VDPAU functionality entirely? Or some sort of
VDPAU-accelerated OpenGL?

I ask because the combination of my frontend and VDPAU-capable video
card isn't fast enough to play using the Standard decoder and the
OpenGL renderer. I realize this is because my frontend's CPU is so
old, but I'd hate to have to upgrade a frontend that is otherwise
perfectly adequate for all foreseeable MythTV uses thanks to
VDPAU. Again, I hope I'm misunderstanding what you're saying.

> Option 6 - Drop XVideo/XvMC support and standardise around OpenGL

I knew this was coming as soon as I read the first sentence in your
message. I agree Xv is on its way out, but to drop it so soon would
be, well, too soon. I'd bet that Xv is still the most-popular
decoder/renderer used, with VDPAU second; even if I'm wrong and VDPAU
is nowadays the most popular, Xv can't be too far behind. It's still
remarkably usable on low-end gear; if my VDPAU-capable card were to
die today I could pop in a non-VDPAU Nvidia card and revert to the
software-decoder/Xv-renderer that was the status quo for 1080i HD
playback for more than three years before VDPAU came along in early
2009.

I know VDPAU-capable cards are very inexpensive. I know ION-based
frontends are $200. I know that ultimately the decision is up to what
the commit-enabled developers are interested in using and supporting;
we saw that with 0.22's dropping of PVR-350 output. Unlike the
PVR-350, though, any Xv-support drop wouldn't be because no one still
has an Xv-capable card, or because Xv output is insufficient to play
current (MPEG-2) HD recordings.

The Xv "problem," such as it is, is inherently a self-solving one. As
more and more MythTV users buy HD-PVRs or in some other way move to
h.264 recordings, Xv will suddenly be inadequate. The masses aren't
there yet, though, and it would be a pity to drop too soon a
well-tested and popular video-output solution.

--
Frontend/backend: P4 3.0GHz, 1.5TB software RAID 5 array
Backend: Quad-core Xeon 1.6GHz, 6.6TB sw RAID 6
Video inputs: Four high-definition over FireWire/OTA
Accessories: 47" 1080p LCD, 5.1 digital, and MX-600
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

raymond at wagnerrp

Mar 23, 2010, 11:15 AM

Post #9 of 34 (3720 views)
Permalink

Re: MythUI OSD branch and the way forward [In reply to]

On 3/23/2010 14:04, Yeechang Lee wrote:
> I am displaying my ignorance here, but are you talking about someday
> bypassing the VDPAU functionality entirely? Or some sort of
> VDPAU-accelerated OpenGL?
>

The latter. Frames would be decoded in VDPAU, before being converted
into OpenGL surfaces and composited with other UI elements.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

simon at koala

Mar 23, 2010, 1:46 PM

Post #10 of 34 (3710 views)
Permalink

Re: MythUI OSD branch and the way forward [In reply to]

On 03/23/10 04:04, Mark Kendall wrote:
> On linux VDPAU will handle the rendering basics well enough but in the
> future we may want to use OpenGL rendering directly. Any VDPAU capable
> card also has sufficient OpenGL horsepower.
what about people who have ATI graphics?
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

robert.mcnamara at gmail

Mar 23, 2010, 1:51 PM

Post #11 of 34 (3710 views)
Permalink

Re: MythUI OSD branch and the way forward [In reply to]

On Tue, Mar 23, 2010 at 1:46 PM, Simon Kenyon <simon [at] koala> wrote:
> On 03/23/10 04:04, Mark Kendall wrote:
>>
>> On linux VDPAU will handle the rendering basics well enough but in the
>> future we may want to use OpenGL rendering directly. Any VDPAU capable
>> card also has sufficient OpenGL horsepower.
>
> what about people who have ATI graphics?

Those people should also have sufficient GL horsepower as I understand
it. Since the proposed approach is nearly exactly what you find in
XBMC and Boxee, if your hardware copes with that, it would cope with
this.

Robert
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

lsorense at csclub

Mar 23, 2010, 1:51 PM

Post #12 of 34 (3708 views)
Permalink

Re: MythUI OSD branch and the way forward [In reply to]

On Tue, Mar 23, 2010 at 08:46:48PM +0000, Simon Kenyon wrote:
> On 03/23/10 04:04, Mark Kendall wrote:
>> On linux VDPAU will handle the rendering basics well enough but in the
>> future we may want to use OpenGL rendering directly. Any VDPAU capable
>> card also has sufficient OpenGL horsepower.
> what about people who have ATI graphics?

I just feel sorry for them, given the pathetically sad drivers they have
to deal with. :(

--
Len Sorensen
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

danielk at cuymedia

Mar 23, 2010, 2:17 PM

Post #13 of 34 (3712 views)
Permalink

Re: MythUI OSD branch and the way forward [In reply to]

On Tue, 2010-03-23 at 12:04 +0800, Mark Kendall wrote:
<snip>

Before this discussion devolves, enough devs have spoken
up for XVideo that it will not be removed anytime soon.

As for statistics, if someone writes the code and it is
opt-in I don't see a problem with it. But unless someone
at least volunteers to write such code there is no point
in discussing it. Any such project should send the data
to services.mythtv.org and the server end needs to be
written as well as the client end.

-- Daniel

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

mtdean at thirdcontact

Mar 23, 2010, 2:21 PM

Post #14 of 34 (3697 views)
Permalink

Re: MythUI OSD branch and the way forward [In reply to]

On 03/23/2010 04:51 PM, Robert McNamara wrote:
> On Tue, Mar 23, 2010 at 1:46 PM, Simon Kenyon wrote:
>
>> On 03/23/10 04:04, Mark Kendall wrote:
>>
>>> On linux VDPAU will handle the rendering basics well enough but in the
>>> future we may want to use OpenGL rendering directly. Any VDPAU capable
>>> card also has sufficient OpenGL horsepower.
>>>
>> what about people who have ATI graphics?
>>
> Those people should also have sufficient GL horsepower as I understand
> it. Since the proposed approach is nearly exactly what you find in
> XBMC and Boxee, if your hardware copes with that, it would cope with
> this.
>

Remember, this has nothing to do with VDPAU support or lack thereof.

Basically, AFAIU, the proposed change should work fine with GeForce 6
series and higher cards from nvidia (and perhaps with even older cards,
such as the GeForce 5 series--but with a little more effort required to
make them work). Similarly-featured cards from other manufacturers with
proper driver support would also work.

Also, note that the GF 6 series cards are 2004-vintage cards, and GF 5
series are 2003-vintage cards. And, if your existing cards won't work,
you need not worry--just don't upgrade your software until you finally
get around to upgrading your old hardware.

No one says you /have/ to run the current version of MythTV--just like
no one says you /have/ to buy new video cards when yours are 6 years
old. But, if you /choose/ not to...

Mike
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

simon at koala

Mar 24, 2010, 2:37 AM

Post #15 of 34 (3652 views)
Permalink

Re: MythUI OSD branch and the way forward [In reply to]

On 23/03/2010 21:21, Michael T. Dean wrote:
>
> No one says you /have/ to run the current version of MythTV--just like
> no one says you /have/ to buy new video cards when yours are 6 years
> old. But, if you /choose/ not to...
>
>
i don't buy graphics cards for machines that run myth - i use the
graphics chip on the motherboard
and therefore i only buy motherboards with integrated graphics

nowadays it is getting harder to find AMD motherboards with NVidia

i've been running the current version of myth for many years now - i'm
not going to stop updating it
--
simon
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

bill at bbqninja

Mar 24, 2010, 3:28 AM

Post #16 of 34 (3646 views)
Permalink

Re: MythUI OSD branch and the way forward [In reply to]

On Wed, Mar 24, 2010 at 8:37 PM, Simon Kenyon <simon [at] koala> wrote:
> On 23/03/2010 21:21, Michael T. Dean wrote:
>>
>> No one says you /have/ to run the current version of MythTV--just like
>> no one says you /have/ to buy new video cards when yours are 6 years
>> old. �But, if you /choose/ not to...
>>
>>
>
> i don't buy graphics cards for machines that run myth - i use the graphics
> chip on the motherboard
> and therefore i only buy motherboards with integrated graphics
>
> nowadays it is getting harder to find AMD motherboards with NVidia
>
> i've been running the current version of myth for many years now - i'm not
> going to stop updating it

I now buy cheap fanless nvidia cards that do VDPAU.
They're:
-under $70 in AU (so likely under $40 in US)
-fanless

Other than that I'm going to likely pick up some ION2 machines once
they're out and have linux driver support. I liked the ION1 but am
too spoiled by advanced2x deint.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

robert.mcnamara at gmail

Mar 24, 2010, 10:08 AM

Post #17 of 34 (3616 views)
Permalink

Re: MythUI OSD branch and the way forward [In reply to]

On Wed, Mar 24, 2010 at 2:37 AM, Simon Kenyon <simon [at] koala> wrote:
>
> i've been running the current version of myth for many years now - i'm not
> going to stop updating it

I suspect you will if your hardware can no longer function with the
demands of the software. Ultimate decision in this case aside, users
of older hardware should expect that we will not support them forever.
You cannot progress forward with any sort of acceptable pace and
continue to support all hardware, forever.

Robert
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

nigel at ind

Mar 24, 2010, 7:34 PM

Post #18 of 34 (3569 views)
Permalink

Re: MythUI OSD branch and the way forward [In reply to]

> PS Nigel - I've deliberately not mentioned OS X quartz/accelerated
> support - mostly because I still can't get trunk to compile on Snow
> Leopard.

Bummer. We should do something about that.

> I do feel however that OS X support should probably be based
> around OpenGL regardless to maintain consistency across platforms.

0.23-fixes could probably be the last with DVDV
(hardware accelerated MPEG support).
I don't know of anyone using it.
(nasty hardware crashes make it unusable for me)

I'm undecided (and ignorant) about Quartz vs OpenGL, though.

--
Nigel Pearson, nigel [at] ind| "Peacemaking is our profession"|
Telstra Net. Eng., Sydney, Australia |Motto of Burpelson Airforce Base|
Office: 9202 3900 Fax: 9212 6348 |Commanded by Gen. Jack D. Ripper|
Mobile: 0408 664435 Home: 9792 6998 | Dr Strangelove |

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

jarod at wilsonet

Mar 24, 2010, 8:11 PM

Post #19 of 34 (3598 views)
Permalink

Re: MythUI OSD branch and the way forward [In reply to]

On Wed, Mar 24, 2010 at 10:34 PM, Nigel Pearson <nigel [at] ind> wrote:
>> PS Nigel - I've deliberately not mentioned OS X quartz/accelerated
>> support - mostly because I still can't get trunk to compile on Snow
>> Leopard.
>
> Bummer. We should do something about that.

Took quite some effort, but I did manage to get it to build under 10.6
a week or two ago, following along with the related thread here. Runs
well enough on my MacBook Pro. Build from 10.6 croaks on my old Mac
Mini, which is still running 10.5 though, and now I've got a newer
xcode on the 10.5 box, so I suspect I need to do the same disable-mmx
hacks to get a build there that works... Blah. Just using xbmc svn
trunk w/the Crystal HD card in the Mac Mini for now.

>> I do feel however that OS X support should probably be based
>> around OpenGL regardless to maintain consistency across platforms.
>
> 0.23-fixes could probably be the last with DVDV
> (hardware accelerated MPEG support).
> I don't know of anyone using it.
> (nasty hardware crashes make it unusable for me)

It never worked well for me either, always crashed and burned.

> I'm undecided (and ignorant) about Quartz vs OpenGL, though.

It'd be nice if there were a way to use Apple's equivalent of vdpau.
Zero cpu usage playing back 1080p h.264 w/quicktime on my MBP, just
like vdpau (nVidia GeForce 9600M GT/9400M graphics combo in this
thing). I'm assuming Apple doesn't expose any interface to it though,
and through quicktime is the only way to access the gpu-based
decoding. Oh well, at least the laptop has plenty of cpu... :)

--
Jarod Wilson
jarod [at] wilsonet
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

freedenizen at gmail

Mar 24, 2010, 11:16 PM

Post #20 of 34 (3538 views)
Permalink

Re: MythUI OSD branch and the way forward [In reply to]

nigel at ind

Mar 25, 2010, 5:03 PM

Post #21 of 34 (3472 views)
Permalink

Re: MythUI OSD branch and the way forward [In reply to]

On Wed, Mar 24, 2010 at 8:11 PM, Jarod Wilson <jarod [at] wilsonet> wrote:
> It'd be nice if there were a way to use Apple's equivalent of vdpau.
> Zero cpu usage playing back 1080p h.264 w/quicktime on my MBP, just
> like vdpau (nVidia GeForce 9600M GT/9400M graphics combo in this
> thing). I'm assuming Apple doesn't expose any interface to it though,
> and through quicktime is the only way to access the gpu-based
> decoding. Oh well, at least the laptop has plenty of cpu... :)

On 25/03/2010, at 5:16 PM, freedenizen wrote:
> I'm poking around looking for info, not sure if they do or not, they
> must expose some items though, adobe is supposed to have some hardware
> acceleration for flash on OS X at some point

As nice as another hardware acceleration thingy would be,
I don't think it can justified, maintenance-wise.

Mark's suggestion of standardising on OpenGL is probably best,
but I suspect there are a few Quartz hooks that we will still need.

Note there is also a patch for CoreVideo somewhere in Trac.
I never applied it for the same maintenance reason
(and, at the time, 10.4 was good enough for me)

--
Nigel Pearson, nigel [at] ind|"Gentlemen! |
Telstra Net. Eng., Sydney, Australia | You can't fight in here-|
Office: 9202 3900 Fax: 9212 6348 | this is the war room!"|
Mobile: 0408 664435 Home: 9792 6998 | Dr Strangelove |

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

stuarta at squashedfrog

Mar 29, 2010, 1:02 PM

Post #22 of 34 (3115 views)
Permalink

Re: MythUI OSD branch and the way forward [In reply to]

On 23/03/2010 20:51, Lennart Sorensen wrote:
> On Tue, Mar 23, 2010 at 08:46:48PM +0000, Simon Kenyon wrote:
>> On 03/23/10 04:04, Mark Kendall wrote:
>>> On linux VDPAU will handle the rendering basics well enough but in the
>>> future we may want to use OpenGL rendering directly. Any VDPAU capable
>>> card also has sufficient OpenGL horsepower.
>> what about people who have ATI graphics?
>
> I just feel sorry for them, given the pathetically sad drivers they have
> to deal with. :(
>

When I bought my perfectly good ATI card, NVidia plain refused to deal
with anyone in the open source community, nor would they entertain the
notion of releasing functioning drivers for the linux platform.

As such the open source ATI driver was far better than the nvidia equiv
and if you really wanted to, ATI had released a functioning driver for
linux.

Oh how the times have changed. 6 months or so after that time nvidia
changed their tune, and i would have been better off buying an nvidia
card. On the bright side, ATI have now released the programming specs
for cards of my era, and apparently even have a dev working on the open
source driver. Thus the drivers for that are coming on rapidly and now
actually have decently functioning GL.

The intel based video card in my main frontend is however a different
story.....

Stuart

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

lsorense at csclub

Mar 29, 2010, 3:12 PM

Post #23 of 34 (3107 views)
Permalink

Re: MythUI OSD branch and the way forward [In reply to]

On Mon, Mar 29, 2010 at 09:02:49PM +0100, Stuart Auchterlonie wrote:
> When I bought my perfectly good ATI card, NVidia plain refused to deal
> with anyone in the open source community, nor would they entertain the
> notion of releasing functioning drivers for the linux platform.
>
> As such the open source ATI driver was far better than the nvidia equiv
> and if you really wanted to, ATI had released a functioning driver for
> linux.

I have yet to encounter an ATI driver for linux that worked well.
They recently discontinued supporting the video cards we bought less
than 2 years ago. Nvidia still supports the ones we bought 6 years ago
in their linux drivers, and the nvidia drivers work (the ati ones last
I fought with them crashed if you didn't explicitly set X to 24 bit in
the config file, and took the whole machine with it).

So they are promising open source support for drivers. Until I see open
source drivers written by the community (ATI has proven to be incompetent
at it after all), I still won't care. It is a shame though given ATI
clearly makes very reliable video cards, accompanied by awful drivers.

> Oh how the times have changed. 6 months or so after that time nvidia
> changed their tune, and i would have been better off buying an nvidia
> card. On the bright side, ATI have now released the programming specs
> for cards of my era, and apparently even have a dev working on the open
> source driver. Thus the drivers for that are coming on rapidly and now
> actually have decently functioning GL.

I switched to nvidia when ATI stopped supporting a 2 year old top of
the line card after promising to fix known bugs in the driver. That was
12 years ago. Nvidia has never done anything like that. They do
eventually move cards to legacy series of drivers, but even then keep
maintaining those as needed for years.

> The intel based video card in my main frontend is however a different
> story.....

Well intel's are tricky. Many have excellent support, and some have none.
Their performance has never been that great though.

I would love an open source openGL driver for linux, but until I see
one, I will keep buying what has working drivers, and so far that's
only nvidia.

--
Len Sorensen
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

simon at koala

Mar 30, 2010, 12:42 AM

Post #24 of 34 (3074 views)
Permalink

Re: MythUI OSD branch and the way forward [In reply to]

On 29/03/2010 23:12, Lennart Sorensen wrote:
> On Mon, Mar 29, 2010 at 09:02:49PM +0100, Stuart Auchterlonie wrote:
>
>> When I bought my perfectly good ATI card, NVidia plain refused to deal
>> with anyone in the open source community, nor would they entertain the
>> notion of releasing functioning drivers for the linux platform.
>>
>> As such the open source ATI driver was far better than the nvidia equiv
>> and if you really wanted to, ATI had released a functioning driver for
>> linux.
>>
> I have yet to encounter an ATI driver for linux that worked well.
> They recently discontinued supporting the video cards we bought less
> than 2 years ago. Nvidia still supports the ones we bought 6 years ago
> in their linux drivers, and the nvidia drivers work (the ati ones last
> I fought with them crashed if you didn't explicitly set X to 24 bit in
> the config file, and took the whole machine with it).
>
> So they are promising open source support for drivers. Until I see open
> source drivers written by the community (ATI has proven to be incompetent
> at it after all), I still won't care. It is a shame though given ATI
> clearly makes very reliable video cards, accompanied by awful drivers.
>
>
>> Oh how the times have changed. 6 months or so after that time nvidia
>> changed their tune, and i would have been better off buying an nvidia
>> card. On the bright side, ATI have now released the programming specs
>> for cards of my era, and apparently even have a dev working on the open
>> source driver. Thus the drivers for that are coming on rapidly and now
>> actually have decently functioning GL.
>>
> I switched to nvidia when ATI stopped supporting a 2 year old top of
> the line card after promising to fix known bugs in the driver. That was
> 12 years ago. Nvidia has never done anything like that. They do
> eventually move cards to legacy series of drivers, but even then keep
> maintaining those as needed for years.
>
>
>> The intel based video card in my main frontend is however a different
>> story.....
>>
> Well intel's are tricky. Many have excellent support, and some have none.
> Their performance has never been that great though.
>
> I would love an open source openGL driver for linux, but until I see
> one, I will keep buying what has working drivers, and so far that's
> only nvidia.
>
>
the issue for me is that nvidia have left the chipset business - so no
more motherboards with integrated nvidia graphics.
intel make their own chipsets - but the performance for graphics is not
very good
amd own ati - so ati (for the forseeable future) will be the only option
for decent integrated graphics

the only machines that i posess that have cards in them are my backends.
i do not want to have to add graphics cards to frontends
hence my interest in ati - nothing religious - just practical considerations
--
simon
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

bill at bbqninja

Mar 30, 2010, 3:23 AM

Post #25 of 34 (3049 views)
Permalink

Re: MythUI OSD branch and the way forward [In reply to]

On Tuesday, March 30, 2010, Simon Kenyon <simon [at] koala> wrote:
> On 29/03/2010 23:12, Lennart Sorensen wrote:
>
> On Mon, Mar 29, 2010 at 09:02:49PM +0100, Stuart Auchterlonie wrote:
>
>
> When I bought my perfectly good ATI card, NVidia plain refused to deal
> with anyone in the open source community, nor would they entertain the
> notion of releasing functioning drivers for the linux platform.
>
> As such the open source ATI driver was far better than the nvidia equiv
> and if you really wanted to, ATI had released a functioning driver for
> linux.
>
>
> I have yet to encounter an ATI driver for linux that worked well.
> They recently discontinued supporting the video cards we bought less
> than 2 years ago. �Nvidia still supports the ones we bought 6 years ago
> in their linux drivers, and the nvidia drivers work (the ati ones last
> I fought with them crashed if you didn't explicitly set X to 24 bit in
> the config file, and took the whole machine with it).
>
> So they are promising open source support for drivers. �Until I see open
> source drivers written by the community (ATI has proven to be incompetent
> at it after all), I still won't care. �It is a shame though given ATI
> clearly makes very reliable video cards, accompanied by awful drivers.
>
>
>
> Oh how the times have changed. 6 months or so after that time nvidia
> changed their tune, and i would have been better off buying an nvidia
> card. On the bright side, ATI have now released the programming specs
> for cards of my era, and apparently even have a dev working on the open
> source driver. Thus the drivers for that are coming on rapidly and now
> actually have decently functioning GL.
>
>
> I switched to nvidia when ATI stopped supporting a 2 year old top of
> the line card after promising to fix known bugs in the driver. �That was
> 12 years ago. �Nvidia has never done anything like that. �They do
> eventually move cards to legacy series of drivers, but even then keep
> maintaining those as needed for years.
>
>
>
> The intel based video card in my main frontend is however a different
> story.....
>
>
> Well intel's are tricky. �Many have excellent support, and some have none.
> Their performance has never been that great though.
>
> I would love an open source openGL driver for linux, but until I see
> one, I will keep buying what has working drivers, and so far that's
> only nvidia.
>
>
>
> the issue for me is that nvidia have left the chipset business - so no more motherboards with integrated nvidia graphics.
> intel make their own chipsets - but the performance for graphics is not very good
> amd own ati - so ati (for the forseeable future) will be the only option for decent integrated graphics
>
> the only machines that i posess that have cards in them are my backends. i do not want to have to add graphics cards to frontends
> hence my interest in ati - nothing religious - just practical considerations
> --
> simon
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>

what makes you think they're ditching integrated? Ion2 isn't even ga yet...
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads