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

[Oliver Endriss]

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

-- 
--------------------------------------------------------
VDR Remote Plugin 0.3.9 available at
http://www.escape-edv.de/endriss/vdr/
--------------------------------------------------------