[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