[mythtv] Video Output patch v13

[Daniel Kristjansson]

On Tue, 2005-04-19 at 22:46 -0400, Daniel Kristjansson wrote:
This is an update on the Xv/XvMC patch.
The patch is here:
   http://www.mrl.nyu.edu/~danielk/mythtv/xv-xvmc-merge-v13.patch.bz2

> However, there is still a problem with Jumping backward and forward
> in HDTV. My guess is that DiscardFrames() may need to be more
> aggressive, i.e. hide visible XvMC surfaces so that more frames can
> be freed, or discard old pause frames more quickly. But I need to do
> some more debugging. This is not causing a playback lockup, but only
> because I'm resetting videoout in NVP after 10 prebuffering waits.

I believe I have fixed the OSD problem in HDTV. By that I mean there
are no lockups and frames don't seem to get lost.  Basically, I've
made DiscardFrames more aggressive by Syncing all displayed frames,
while making at the same time it less aggressive by using the
VideoOutputXv::DiscardFrame() to discard frames, which ensures
that any frames for which an OSD blend frame is showing does not
get discarded. 

On my early model Geforce FX card I can pop up a non-transparent OSD
without problems, while the non-transparent OSD no jump forward and
back causes some studdering. Transparent OSD's make the problem worse.
I don't expect OSD to work with HDTV until we have chromakey OSD, but
at least this does not seem to be losing frames.

I've also fixed the missing progress bar and bad end time on playing
back recordings with XvMC, this was caused by SyncPositionMap() in
DecoderBase not functioning on the second AVFD::OpenFile(),
needed to reinit ffmpeg with a different video codec. The solution
was to simply not call it on opening the same file a second time.

This does point to another problem in avformatdecoder, the 800-1000
hour recording time estimations for one hour programs were based on
the calculated bit rate, obviously the calculated bit rate is way
off, this could cause serious problems with buffering.

-- Daniel