MythTV Developers Plan Xv, XvMC, OpenGL Changes

[Elv13]

As a Myth user, I can say I am happy to finally ear some devs trying to reach XBMC. That UI is so nice and flexible, while MythUI is clearly (visually) outdated and unanimated. But MythTV is just the best when it come to feature with 1 thousand mile lead on XMBC (1000computer years = a decade in normal users life). I do use Xv, but I will upgrade my hardware just to get XBMC like UI with Myth.

[dargllun]

On the contrary, we welcome users using their existing hardware with their existing versions of MythTV. You will be able to use MythTV 0.24 for as long as you want.

While fully understanding your points, it is worthwhile to point out that past stable releases apparently receive no or nearly no support once there is a new one. At least on ythtv-users@ I read several times when people asked about 0.23.1 they where referred to 0.24 with the comment that 0.23.1 wouldn't be supported.

Again, I understand your point an in the end its a question of manpower if you want to support many versions. If you don't have the people to do it, then you can't do it.

[dargllun]

Phoronix: MythTV Developers Plan Xv, XvMC, OpenGL Changes
While the MythTV developers didn't comment on what video API they will be targeting for the Intel/ATI support, it's safe to assume it will be VA-API.

VAAPI is an API Which they apparently don't like (for good reasons):

VAAPI is still a moving target in almost every respect and I've yet to see a stable implementation (I have tested the VAAPI implementations on other linux players and was never satisfied - so not just a MythTV issue)

What ATI users really need is a VDPAU state tracker for Gallium and the fixing of the performance bottlenecks. (See past coverage of this on Phoronix.) The *VAST* majority of myth users and devs is on NV hardware doing vdpau, and I believe that's not going to change soon.

Ok, another option would be AMD implementing VDPAU but I think it's much more likely to see a Gallium port to C64 GEOS...

[gbeauche]

VAAPI is an API Which they apparently don't like (for good reasons):

Your link doesn't list any good reason.

Ok, another option would be AMD implementing VDPAU but I think it's much more likely to see a Gallium port to C64 GEOS...

Changing the API (front-end) doesn't matter when the driver is innerly broken...

[dargllun]

Your link doesn't list any good reason.

I quoted what I understood was the good reason - VAAPI is considered unstable in terms of its definition as well as its rendering stability.

If your assessment is different - fair enough. Speaking as who you are, would it then make serious sense for me to install Catalyst, your vaapi->vdpau bridge and be happy?

[curaga]

Is the fancy OSD really good enough reason to drop several generations of hardware?

Even on R700 hw, XV is an improvement over GL output. And the difference grows for every generation you go towards the older end.

Where, at the end, you have Trident, Matrox and Mach64 cards that play silky smooth on XV but GL is measured in frames per minute.

[gbeauche]

I quoted what I understood was the good reason - VAAPI is considered unstable in terms of its definition as well as its rendering stability.

The video rendering API has not changed for 6 months when VA/GLX was integrated upstream. Prior to that, the VA/X11 parts have not changed for 21 months when va_x11.h was moved into the va/ subdirectory. The video decoding API has not changed for 1 year when an extra field was added to the MPEG-4 ASP struct. Besides, an API can hardly affect rendering stability. This depends on the driver (implementation)...

If your assessment is different - fair enough. Speaking as who you are, would it then make serious sense for me to install Catalyst, your vaapi->vdpau bridge and be happy?

... but the ATI situation is crap. Some people are happy though, but I am not. The driver still contains important bugs. You don't see some of them because I used workarounds in the xvba->vaapi bridge at the expense of performance and memory. Even initialization code does not work as specified. An undocumented behaviour has to be used to workaround some silliness in the API. One example among many others.

[Kano]

How long would it take to create a wrapper from vaapi to vdpau? You did it once in the other way, so it would be cool to have the other side especially for the new flash player - h264 l5.1 support is not needed as in most cases only l4.0 is used - like youtube. I think you can specify another vdpau driver with an enviroment var, so basically it should be possible...

[gbeauche]

How long would it take to create a wrapper from vaapi to vdpau? You did it once in the other way, so it would be cool to have the other side especially for the new flash player

I don't think this will be necessary, anyway. Besides, this is not possible for the way Adobe uses VDPAU to achieve this. In particular, the VDPAU/GL API is not self-contained to VDPAU, it's spread over OpenGL. So, this would require changes to all OpenGL drivers... What do you do with binary only drivers?

[gbee]

That UI is so nice and flexible, while MythUI is clearly (visually) outdated and unanimated.

The 'outdated' bit has more to do with the themes than limitations of MythUI. MythUI does support some animation, it's just not all enabled or used in themes to any significant degree currently. The library was designed from the ground up with animation in mind though. As the developer who put the most work into MythUI over 18 months of development I can be a bit sensitive about criticism. What we really need is more themers to give MythUI a good workout, it's an order of magnitude more capable than the previous UI. Try to remember what it looked like back in 0.20.

Is the fancy OSD really good enough reason to drop several generations of hardware?

The switch to OpenGL for video rendering is about far more than the OSD. It's not least about code simplification, allowing us to focus on a single powerful cross-platform solution. It will also allow us to integrate the UI and video so that they are no longer two completely separate modes but a seamless experience. With OpenGL we can easily allow users to see video previews integrated into the list of recordings and video, browsing of rss feeds whilst video plays in the background and video continue to play smoothly as it's resized from a small preview window to fullscreen. These examples are limited by my imagination and my ability to communicate the benefits. If you can't understand what I'm trying to convey then you will just have to trust me when I say that is well worth sacrificing support for the oldest generations of hardware.

These screenshots might help to illustrate just one of the reasons we don't like X-Video:

First the OSD on a standard definition recording with VDPAU - http://miffteevee.co.uk/imagebin/osd_font_vdpau.png

Now that same OSD with the same recording using XVideo - http://miffteevee.co.uk/imagebin/osd_font_xv2.png

The above is a generous example, full resolution PAL, the lower the original video resolution the poorer the quality of the OSD so it's worse with NTSC/SD-ATSC and completely useless with videos/recordings below those resolutions. Also worth noting is that the OSD will match the video dimensions with Xv, so a 4:3 SD recording on a 16:9 screen the OSD will be squashed horizontally, vertically for a 2.35:1 film on the same screen and you can imagine how 2.35:1 on a 4:3 screen might be unusable.

We know not everyone cares about a better looking and more capable user interface. It's been made quite clear to us that it's what most users want. To be brutally honest it's also what interests the developers, which is usually a significant factor in a volunteer run project.

I'll finish by repeating that this is a long way off in the future. There is every reason to believe that drivers for existing ATi and Intel hardware will have much improved 2D OpenGL support by that time. Hardware has been capable of it for years, were we not playing 3D computer games using OpenGL ten years ago?