[mythtv-commits] Ticket #9216: opengl output: video stuck

MythTV noreply at mythtv.org
Sun Jun 19 11:53:38 UTC 2011


#9216: opengl output: video stuck
------------------------------+----------------------------
 Reporter:  anonymous         |          Owner:  markk
     Type:  defect            |         Status:  closed
 Priority:  major             |      Milestone:  0.24.1
Component:  MythTV - General  |        Version:  0.24-fixes
 Severity:  medium            |     Resolution:  Fixed
 Keywords:                    |  Ticket locked:  0
------------------------------+----------------------------
Changes (by markk):

 * status:  assigned => closed
 * resolution:   => Fixed


Comment:

 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.

-- 
Ticket URL: <http://code.mythtv.org/trac/ticket/9216#comment:22>
MythTV <http://code.mythtv.org/trac>
MythTV Media Center


More information about the mythtv-commits mailing list