[mythtv-commits] mythtv commit: r8841 by danielk

[mythtv@cvs.mythtv.org]

      Author: danielk
        Date: 2006-02-02 18:06:32 +0000 (Thu, 02 Feb 2006)
New Revision: 8841
   Changeset: http://cvs.mythtv.org/trac/changeset/8841

Modified:

   trunk/mythtv/libs/libmythtv/NuppelVideoPlayer.cpp
   trunk/mythtv/libs/libmythtv/NuppelVideoPlayer.h
   trunk/mythtv/libs/libmythtv/RingBuffer.cpp
   trunk/mythtv/libs/libmythtv/RingBuffer.h
   trunk/mythtv/libs/libmythtv/avformatdecoder.cpp
   trunk/mythtv/libs/libmythtv/decoderbase.h
   trunk/mythtv/libs/libmythtv/ivtvdecoder.cpp
   trunk/mythtv/libs/libmythtv/nuppeldecoder.cpp
   trunk/mythtv/libs/libmythtv/tv_rec.cpp

Log:

Fixes #971. Fixes #900.

In SwitchToProgram() we check if we close to the end before doing a switch. This was safe for low bitrate programs, but with high bitrate programs the RingBuffer was initialized with a larger readblocksize. Also the valid video frames check isn't terribly valid with nVidia XvMC, which uses a total of only 8 video buffers.

This reworks this check and moves it to NVP::IsReallyNearEnd(). It uses information from the RingBuffer to set the thresholds so it scales with different bitrates. Also, the ringbuffer now takes the play_speed into account when using timestretch. The raw bitrate as reported by ffmpeg is scaled by timestretch value. Also since IsReallyNearEnd() is using the real readblocksize in it's calculations, I've applied John Poet's patch for making 1080i @ >=1.2 timestretch work by increasing the readblocksize.

The params may need some tuning for the best performance. The values I used are both theoretically safe and worked for the 400 ringbuffer switches I threw at it. But the params are somewhat conservative. When I used the theoretical minimums, I did observe a lockup after about 70 switches, so my model isn't perfect.