[mythtv-commits] mythtv commit: r9893 by danielk

mythtv at cvs.mythtv.org mythtv at cvs.mythtv.org
Tue May 9 15:35:45 EDT 2006


      Author: danielk
        Date: 2006-05-09 19:35:44 +0000 (Tue, 09 May 2006)
New Revision: 9893
   Changeset: http://cvs.mythtv.org/trac/changeset/9893

Modified:

   branches/mythtv-vid/libs/libmythtv/NuppelVideoPlayer.cpp
   branches/mythtv-vid/libs/libmythtv/videoout_xv.cpp

Log:

Fixes the pause frame problem with XvMC with IA44 blended OSD.

The problem was that DoFastForward() called ClearAfterSeek() which ends up calling VideoOutput::DiscardFrames(true), where true is the 'next_frame_keyframe' param. If the next frame is not in fact a keyframe we end up Discarding more buffers than is safe. The other problem was that we weren't handing next_frame_keyframe properly for XvMC video out.

Now we finish rendering all the used surfaces, so that as long as avlib is done with the frame, so is XvMC. We also add them to the displayed queue and then check that queue to see if the frames can be made available to avlib as blank frames, instead of adding them directly to the available queue. Finally, if next_frame_keyframe is set we do this for frames in limbo as well (i.e. to frames which avlib was still writing data to before the seek.). We don't do this to pause frames, as this messes up backward frame-by-frame seeking, where DiscardFrames(true) is still called when it shouldn't be.

I've tested this with fast forward and rewind as well as seeking in pause and in edit mode. I haven't tested this with video output modes other than X11 ones, nor with commercial flagging or transcoding. I don't imagine this would effect the flagging or transcoding, but NVP changes sometimes do.






More information about the mythtv-commits mailing list