opengl output: video stuck

[anonymous]

With Radeon HD 3200, KMS, xorg-edgers: when selecting opengl output, the image is stuck. I read somewhere that the opengl sync is (temporarily?) disabled.

[anonymous]

See also: http://www.mythtv.org/wiki/Release_Notes_-_0.24 (look for "Disable OpenGL vsync") ​http://svn.mythtv.org/trac/changeset/26314

[stuartm]

This has nothing to do with opengl vsync.

We need logs with -v playback please and --version output. Please read the TicketHowTo.

[anonymous]

Hi:

I am also using xorg-edgers and a ATI Radeon card, HD4850 in my case (RV770).

My system is kubuntu 10.10 with xorg-edgers' ati+radeon driver 6.13.99+git20101111.51e51f86 version and mythtv 0.24.0+fixes27204 from the mythbuntu ppa repository.

I get the image stuck problem when using opengl output with the classic mesa driver (r600). The problem does not show when I use the gallium driver (r600g). I am attaching two logs: one with the classic mesa driver and another one with the gallium driver.

If more info is needed, please tell me, and I will try to help as much as possible.

[robertm]

It is highly unlikely that open source drivers provide adequate GL extensions and performance to work properly with Myth. Why are you not using fglrx? What happens when you do?

[anonymous]

Mesa r600 classic log

[anonymous]

Mesa r600g gallium log

[anonymous]

I was not really looking into installing fglrx. Classic mesa used to work with mythtv 0.24 svn until 3 or 4 weeks ago. From that moment the "image stuck" problem showed up. Gallium continued working and still does, so I thought it was just a bad commit in the classic mesa code. However, when I saw this ticket I just wanted to add the logs so that it can be possibly worked out.

My experience so far with the open source drivers and mythtv is that with openGL output they are capable of playing back HD content (1080i). I am using openGL output because the XV output shows incorrect colours (strange because mplayer shows correct colours. If I have time I will look into that as well).

[markk]

To the original anonymous poster - can you please attach logs as requested previously,

To the second anonymous poster - you may have the same symptom but please bear in mind that it is entirely possible the cause is totally different. There are many different issues that can can cause blank OpenGL playback. Can you confirm whether or not you updated your mesa driver at the same time you saw the problem start? I don't think there have been any commits that touch opengl video playback in some time (though my memory could be flaky) and there are no obvious problems in your the log.

To both anonymous posters - this is going to be impossible to debug if we have to second guess which comments and logs belong to whom. Please set some sort of id/email address using the preferences page.

[greg]

original poster - mythtv version used

[greg]

original poster - frontend log

[greg]

I'm the original poster and have now attached the logs as requested.

The second poster was correct, I'm using the open source classic r600 drivers. So far I have only the best experiences with the OSS drivers and myth, fglrx always gave me tearing and less control over video modes. so I'd really like to continue using those drivers. Also, I'm still hoping that maybe someday we'll see a vdpau gallium tracker, but that's a different story :-)

@robertm - is the mesa opengl really that bad for use with mythtv? do you need opengel > 2.1?

[greg]

Note: I'm adding this for completeness; r600g (gallium) is highly experimental and can't seriously be expected to work well in all situations.

When I just tried the r600g drivers which caused screen corruption and an immediate system reset. What I did is install the libgl1-mesa-dri-experimental from xorg-edgers and run LIBGL_DRIVERS_PATH=/usr/lib/dri/gallium mythtvfrontend. I don't even know if this is the recommended way to do it, or if there's more to be done to properly use gallium drivers.

Again, this is purely informational and even somewhat off-topic...

[markk]

Greg

Your log suggests an opengl performance problem. Can you try adding 'opengloptions=nofrag' to the custom filters box in the the Display Profile settings screen. If that doesn't work, please post the output of 'glxinfo'. thanks

[greg]

Nope, with this option I'm getting a slightly flickering gray image only... I attached the glxinfo output. Let me know what else I could try, and thanks so far.

[anonymous]

I am the second anonymous poster.

The xorg-edgers is a xorg+mesa bleeding-edge repository which follows the trunk git version. Packages are usually updated every two or three days. I recall that the problem started to appear at around the time the mesa trunk became version 7.10 (or one or two weeks after that moment). Looking at my apt history log, the first 7.10 mesa packages were installed on my system on 22 September.

Greg:
I use the same command as you in order to use the gallium driver with mythfrontend. However, for me this driver is quite stable: no systems lockups although I get ocasional segfaults.

[greg]

Replying to anonymous:

I use the same command as you in order to use the gallium driver with mythfrontend. However, for me this driver is quite stable: no systems lockups although I get ocasional segfaults.

Yeah, I don't know what's going on either. I definitey was able to run glxgears with gallium a few month ago, but somehow this doesn't work anymore. In fact reading up on XvBA, vaapi and robertm's comment on OpenGL I'm tempted (yet again) to defect back to Catalyst, but I'm not sure whether 0.24-fixes actually supports va-api?! But that's off-topic, again, sorry for that. I'm happy to continue discussing this via pm dargllun /AT/ googlemail.

[greg]

@markk: *bump* so... any insight from my glxinfo output?

[robertm]

Please do not bump tickets. Especially less than two days after last touching the ticket. We have hundreds of tickets.

[dargllun@…]

Replying to robertm:

It is highly unlikely that open source drivers provide adequate GL extensions and performance to work properly with Myth. Why are you not using fglrx? What happens when you do?

I looked at this issue again last night. With the standard open source radeon driver (KMS, but no gallium) I can happily use "mplayer -vo gl ...". Rough monitoring with top and htop shows only a little more load than "-vo xv". So it looks like myth should be able to perform similarly. Of couse, myth may be using more advanced compositing techniques; still I don't see why this shouldn't work. Probably OpenGL is pretty much tested with nvidia hardware?

With all the recent discussion about the long-term move to opengl we should try to get as many platforms converted as early as possible.

[markk]

A couple of requests:-

• can you please give me an update on how this is working with latest fixes/0.24 and the latest relevant driver versions.

• please try playback with the openg-nohide.diff patch I've attached to this ticket. I don't honestly expect it to help at this stage but I'd like to eliminate a potential windowing issue I've seen elsewhere.

thanks, Mark

[greg]

r600g opengl output, kernel(2x) and onefield deinterlacing

[greg]

r600g opengl output, no deinterlacers

[markk]

Greg,

Just as an FYI, attaching a new file doesn't trigger an update email to the commits list hence I hadn't spotted your logs. Always worth adding an extra comment as well.

wrt the new logs:-

• presumably you are still not seeing any video? is that correct?
• did you try the openg-nohide.diff patch?
• can you try turning off refresh rate switching. i.e. in Setup->Appearance->Video Mode Settings ensure Separate video modes for GUI and TV playback is disabled.
• can you try running the frontend in a window instead of fullscreen. so something like 'mythfrontend -v playback --geometry 1024x576'

Mark

(oh - and I almost forgot, you may want to abandon the OpenGl? kernel deinterlacer for your setup until everything else is working. If your card isn't fast enough or the driver is falling back to software emulation anywhere, playback is going to be pretty broken)

[dargllun@…]

This comment to note that I tried to respond to mythtv-commits. I'm not sure this works since I'm not subscribed to this list. If you don't see a reply, please let me know.

Briefly, I tried your suggestions and it still doesn't work. Without any deints, the output is fairly ok, but looks awful of course. I think the machine should be powerful enough. Even with deint on, the system load isn't at max (70-90%), but the output shows massive judder. --geometry 1024x768 crashes repeatedly, probably due to the r600g drivers.

Thanks Greg

[markk]

Closing as fixed as the root cause of the stuck video was an A/V sync problem that was fixed in afe5669be (master, also fixed in 0.24.1) - which for other reasons was particularly bad with OpenGL video playback.

The remaining problem is a far more generic issue with OpenGL video rendering that is high on my list of priorities. The OpenGL video code is currently tailored for optimising GPU performance and features at the expense of CPU cycles.

In order to greatly simplify the OpenGL deinterlacers, and hence greatly improve their speed, we pack video frames into a 'YUVA' format before transferring them to the GPU. This obviously uses additional CPU cycles as well as adding a slight CPU->GPU memory transfer overhead (the packed frames are 33% larger). The payoff is a single texture sample per pixel - as opposed to 3 that are required for 3 separate Y, U and V frames. That also means each additional sample for deinterlacing only requires one additional texture fetch - which vastly improves performance (e.g. 8 texture samples for the kernel deint vs 24).

The downside is that on systems with slower GPUs, there is a double whammy of extra CPU overhead and a GPU that doesn't complete it's operations in time. Hence the user sees dropped frames with a higher than normal CPU utilisation but potentially still significant CPU headroom to spare.

I'm going to look at adding an alternative OpenGL video rendering profile that uses the more 'traditional' 3 texture approach for faster video frame uploads. This should drop cpu utilisation to more expected levels, giving the necessary headroom for CPU based deinterlacers while retaining the core features of OpenGL rendering (full screen OSD and picture controls). It will not however have OpenGL deinterlacers (although other OpenGL filters may still be available).

The other issues discussed in relation to the open source radeon drivers are not a MythTV issue. As confirmed on the users list, some versions are working and others are not. Given that the OpenGL video code is working as expected on nvidia, amd and intel hardware on windows, os x and linux, I don't believe it is our OpenGL code that is the problem.