[MPlayer-dev-eng] Proposed patch for ASF lock up due to consecutive video packets with no valid PTS.

[Robert Krakora]

Hello:

I am using a Linksys PTZ camera that employs ASF to encapsulate MPEG4
video.  I was seeing the main mplayer process lock up decoding video while
the mplayer forked process was still acquiring HTTP delivered ASF data from
the network connection.  Upon further review I noticed that two back-to-back
ASF packets contained no PTSs.  On the later invalid PTS a gigantic frame
time is calculated and fed to a sleep call from which it never returns (it
may in a week or two).  The patch below attempts to address this (works for
me) by crudely extrapolating the frame time based upon the last frame time
in this instance.  Please review and comment.  ;-)

[root at localhost mplayer]# svn diff
Index: libmpdemux/video.c
===================================================================
--- libmpdemux/video.c  (revision 29748)
+++ libmpdemux/video.c  (working copy)
@@ -426,6 +426,7 @@
     fprintf(stderr, "'\n");
 }

+double last_frame_time = -1.0;
 int video_read_frame(sh_video_t* sh_video,float* frame_time_ptr,unsigned
char** start,int force_fps){
     demux_stream_t *d_video=sh_video->ds;
     demuxer_t *demuxer=d_video->demuxer;
@@ -592,6 +593,12 @@
         double next_pts = ds_get_next_pts(d_video);
         double d= (next_pts != MP_NOPTS_VALUE) ? next_pts - d_video->pts :
d_video->pts-pts1;
         if(d>=0){
+          if (d > 1.0 && last_frame_time > 0.0)
+                d = last_frame_time;
+          else if (d > 1.0)
+                d = frame_time;
+          else
+                last_frame_time = d;

Best Regards,

-- 
Rob Krakora
Senior Software Engineer
MessageNet Systems
101 East Carmel Dr. Suite 105
Carmel, IN 46032
(317)566-1677 Ext. 206
(317)663-0808 Fax