stichnot at gmail
Nov 11, 2009, 8:33 PM
Post #2 of 4
(323 views)
Permalink
|
On Wed, Nov 11, 2009 at 11:44 AM, Jim Stichnoth <stichnot [at] gmail> wrote:
> For quite a while I have noticed that exiting playback and returning
> to the menu is very slow, usually 10-15 seconds. This has been the
> case in both 0.21 and 0.22, and for both VDPAU and Slim profiles.
>
> I added some extra logging to my own build to find out where the
> slowness is happening. Here are the last few calls leading to the big
> pause:
>
> TV::~TV()
> delete player.back();
> PlayerContext::~PlayerContext()
> PlayerContext::TeardownPlayer()
> PlayerContext::SetNVP(NULL)
> pthread_join(decode, NULL)
>
> The pthread_join call takes about 11-12 seconds to complete. Running
> strace shows tons of system calls leading up to pthread_join, but the
> logging output pauses for several seconds at the pthread_join call
> with this line:
> futex(0xad249bd8, FUTEX_WAIT, 13506, NULL) = 0
>
> (The first and third parameters of course change each run.)
>
> Interestingly, I tried running "top -d .25" to see what was going on
> with the CPU during the long pause, but top refuses to update the
> screen during this period.
>
> Any ideas what the problem might be? The possibilities seem to be
> Myth code, the pthreads library, or the kernel. My kernel is
> 2.6.27.9-159.fc10.i686 from MythDora 10.21.
Silly me. Apparently I had at some point modified the Slim profile to
use VDPAU, so both of my tests were actually using VDPAU.
In any case, I thought to add extra logging to the other threads that
the main thread was waiting on. It turns out that the bottleneck is
in VDPAUContext::FreeBuffers(), particularly the call to
vdp_video_surface_destroy(). For some recordings, each call is taking
about 0.6 seconds, and since there is one call for each of the 17
VDPAU buffers, that adds up to 10+ seconds. (For other recordings,
each call might take only half as long; I don't know what the pattern
is.)
So if I want to improve the stop-playback performance, it seems I have
two choices. First, I could try reducing the number of VDPAU buffers.
What is special about 17 buffers? Are there any guidelines on how
many are necessary for a given recording?
Second, I could try setting up a special thread to free the buffers in
the background, with a lock to ensure that another playback doesn't
start until the special thread completes.
Jim
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
|
