[vlc-devel] Re: FW: Patch to video_output.c stops 'late picture skipped' looping

[Sigmund Augdal]

Hi

Good work on analyzing this problem, your reasoning seems good, but I
disagree a bit on your solution. This is mainly because the render time has
nothing to do with the pts delay. There are other constants more suitable
for the purpose ( VOUT_BOGUS_TIME or some other VOUT_* ). 

I also have an alternative solution: what if the sliding mean were weighting
the previous value a bit? the code could then be something like this

----
p_vout->render_time *= 3;
p_vout->render_time += mdate() - current_date;
p_vout->render_time >>= 2;
----

Could you try to see if this work? also try mulitplying with 7 and shifing 3


Sigmund


On Fri, Sep 12, 2003 at 11:13:17AM +1000, Simon Gittins wrote:
> Hi
> 
> I've been having issues where vlc would often stop displaying video and
> continually write "late picture skipped" messages when changing consoles
> (ie between X and text consoles).  I narrowed the problem down to
> RunThread in video_output.c, where the local variable render_time can
> spike if there is a large delay (like receiving a SIGSTOP, or in my
> case, switch terminals).  If render_time ever becomes very large (eg 0.5
> seconds), the check for late pictures will be triggered, and will
> continue to be triggered for all incoming pictures, as the loop will
> always 'coninue;' before being able to reset the render_time to
> something sane.
> 
> The proposed solution is to avoid letting time spikes into the
> render_time 'sliding mean' calculation by checking that the time is not
> above DEFAULT_PTS_DELAY.
> 
> Another solution would be to reset render_time to a reasonable value
> (eg, 0) upon entering the 'late picture skipped' conditional, but I
> imagine that this change could cause more problems than it fixes.
> 
> Probably the best (in terms of reliably filtering out render_time
> spikes) would be to replace the 'sliding mean' with a median (5 entries
> would be sufficient), but this would obviously result in a larger and
> uglier patch.
> 
> I've attached a (very small) patch with the first proposed solution
> diffed to 0.6.2.  I can rediff it to CVS if necessary.
> 
> Please CC me any replies as I am not subscribed to the list.
> 
> Thanks
> Simon Gittins
> 
> --- video_output.c.orig	2003-09-12 11:08:06.000000000 +1000
> +++ video_output.c	2003-09-12 09:32:05.000000000 +1000
> @@ -892,9 +892,18 @@
>           */
>          if( display_date != 0 && p_directbuffer != NULL )
>          {
> -            /* Store render time using a sliding mean */
> -            p_vout->render_time += mdate() - current_date;
> -            p_vout->render_time >>= 1;
> +            /*
> +             * If render_time becomes morbidly high, we will enter a 
> +             * 'late picture skipped' mode, as render_time will never
> be
> +             * updated again.  So prevent spikes from affecting
> render_time
> +             */
> +            mtime_t t = mdate() - current_date;
> +            if( t < DEFAULT_PTS_DELAY )
> +            {
> +                /* Store render time using a sliding mean */
> +                p_vout->render_time += t;
> +                p_vout->render_time >>= 1;
> +            }
>          }
>  
>          /* Give back change lock */
> 
> -- 
> This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
> To unsubscribe, please read http://developers.videolan.org/lists.html
> If you are in trouble, please contact <postmaster at videolan.org>
> 

-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html
If you are in trouble, please contact <postmaster at videolan.org>