Re: [vdr] FF card AV sync problems, possible fix to VDR

Ville Rannikko wrote:

Hi!

The newest firmware for FF cards did not completely fix the AV desync problems for me.

Can you provide a sample recording where A/V sync fails with the current firmware?

According to information from Werner the problem happens when small video frames fill the decoder buffer with over 2 seconds of data. So I made this patch for dvbplayer.c to stop it from uploading more PES frames to decoder when STC/PTS difference is more than 2 seconds. This seems to fix the remaining problems for me, but I have not tested it much. The PTS/STC-code has been mostly taken from the dvb-subtitles plugin. Comments, please

The driver accepts as much data as the driver buffers can hold: - max. 192 KByte video - max. 64 KByte audio

The firmware requests data from the driver. The driver does not push data to the firmware without request from the firmware.

Until now I do not understand how there could be any over/underflows during normal operation.

--- dvbplayer.c.orig 2007-01-31 18:21:42.000000000 +0200 +++ dvbplayer.c 2007-01-31 18:35:36.000000000 +0200 @@ -495,6 +495,51 @@ } } if (p) {

•             if(playMode == pmPlay && pc > 13)
  

•               {
  

•                 int64_t stc = -1;
  

•                 int64_t pts = -1;
  

•                 if ( p[0] == 0x00 && p[1] == 0x00 && p[2] == 0x01)
  

•                   {
  

•                     if(p[7] & 0x80)
  

•                       {
  

•                         switch( p[3] )
  

•                           {
  

•                           case 0xE0 ... 0xEF: // video
  

•                           case 0xC0 ... 0xDF: // audio
  

•                             pts  = (int64_t) (p[ 9] & 0x0E) << 29 ;
  

•                             pts |= (int64_t)  p[ 10]         << 22 ;
  

•                             pts |= (int64_t) (p[ 11] & 0xFE) << 14 ;
  

•                             pts |= (int64_t)  p[ 12]         <<  7 ;
  

•                             pts |= (int64_t) (p[ 13] & 0xFE) >>  1 ;
  

•                           }
  

•                       }
  

•                   }
  

•                 if(pts != -1)
  

•                   {
  

•                     cDevice *pd = cDevice::PrimaryDevice();
  

•                     if(pd)
  

•                       {
  

•                         stc = pd->GetSTC();
  

•                         if(stc != 0)
  

•                           {
  

•                             if(pts & (int64_t)1<<32)
  

•                               {
  

•                                 stc |= (int64_t)1<<32;
  

•                               }
  

•                             int64_t timeDiff = (pts-stc);
  

•                             if (pts<stc)
  

•                               {
  

•                                 timeDiff += (int64_t)1<<33;
  

•                               }
  

•                             timeDiff /= 90;
  

•                             if(timeDiff > 2000)
  

• 		   cCondWait::SleepMs(timeDiff - 2000);
  

•                           }
  

• 	   }
  

•        }
  

•    }
             int w = PlayPes(p, pc, playMode != pmPlay);
             if (w > 0) {
                p += w;
  

Hm, that patch does not look like a real bug fix to me. ;-) It is a workaround which limits the total buffer capacity to max 2s. I guess this works because it somehow triggers a resync in the firmware.

Anyway, fixes must be applied to the firmware or driver, not to VDR.

But let's analyse the problem first. We need a sample recording...

Oliver