[mythtv-users] Exiting playback is very slow

[Jim Stichnoth]

On Wed, Nov 11, 2009 at 11:44 AM, Jim Stichnoth <stichnot at gmail.com> 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