XvMC (w/nVidia drivers) can run out of frames

[sean@…]

I have tried to isolate what causes the channel change problems and can only ascertain that it occurs when Standard XvMC is selected AND a deinterlacer is specified (Standard and deint works fine and XvMC and no deint seems to work fine) When changing channels under this condition I am presented with a blank screen, I then hit escape to get back into the menu and then go back to live tv and then the channel is viewed properly - There must be a problem in the channel change routine The log below is simply me viewing channel 1737 then changing channels to 1738 (this presents me with a blank screen, not sure if the "Parser not found for Codec Id: 94211 !" is the problem. I then press escape to go back into the menu and then go back into live tv, it then tunes channel 1738 and displays it perfectly. If you need any more logs with different verbosities I'm quite happy to arrange that (please email me!)

btw I'm running MythTV Subversion 8427

[sean@…]

Played around a little more... doesn't seem to be related to deint - seems to be intermittent and only occurs when XvMC is enabled (I would have thought that it could be the NVIDIA drivers but this used to work perfectly in the latest stable code)

-- Sean

[danielk]

This also happens if you try to edit with XvMC enabled when using the nVidia XvMC implementation.

[danielk]

(In [9881]) Refs #906. Fix for nVidia XvMC with traditional blended OSD or Chromakey OSD which leaked "D"isplayed frames.

The problem was that when CheckDisplayedFramesForAvailability?() was called it wasn't always possible to free the frames because they were still on screen or being rendered. This was especially a problem when skipping forward several times in a row without letting the video play between skips. Each skip would leak two frames that couldn't be recovered until playback resumed, if you leaked enough frames playback couldn't be resumed at all so you would just get prebuffer pause warnings forever.

This renames CheckDisplayedFramesForAvailability?() to CheckFrameStates?() and makes it a public virtual method available in VideoOutput?. By default it does nothing, but if you are using XvMC it rechecks all the displayed frames to see if they are available for use by the the decoder. Also whenever prebuffering is started in the NVP this is called, so that the prebuffering pause should eventually end, usually quickly enough so that the pause is not noticable.

[danielk]

Fixed by [9915].

[danielk]

(In [10143]) Refs #906. Refs #137. Backports XvMC fixes from SVN head to 0.19-fixes.

This is slightly more hackish than the fix in head, because I didn't backport some of the NVP fixes that simplify the XvMC fixes there.

But I've made hundreds of channel changes and many skips and playback speed changes and it only gave me stuttering once vs. 10% of the time without the fixes.