[MPlayer-dev-eng] [PATCH] further dvr-ms playback improvements

[Nico Sabbi]

Trent Piepho wrote:

>On Wed, 27 Sep 2006, John Donaghy wrote:
>  
>
>>I've attached an improved patch that works by continuously
>>recalculating the  'average frame time' rather than simply reading it
>>from the container. The reason for doing it this way is that the value
>>in the container is wrong in at least one example I have (it may well
>>be wrong for all HD recordings).
>>    
>>
>
>+ asf->avg_vid_frame_time = (float)((double)time*0.001f/(double)asf->vid_frame_ct);
>
>Since avg_vid_frame_time is a double, what is the point of the float cast?
>Also, floating point constants are type double by default.  Just use this:
>
>asf->avg_vid_frame_time = time*0.001/asf->vid_frame_ct;
>  
>

also, code like this:

-        if (get_ext_stream_properties(hdr, hdr_len, streamh->stream_no, 
&asf->avg_vid_frame_time)) {
-         sh_video->frametime=(float)asf->avg_vid_frame_time;
-         sh_video->fps=1.0f/sh_video->frametime;
-        } else {
-         asf->avg_vid_frame_time=0.0; // only used for dvr-ms when > 0.0
-         sh_video->fps=1000.0f;
-         sh_video->frametime=0.001f;
-        }
+        //if (get_ext_stream_properties(hdr, hdr_len, 
streamh->stream_no, &asf->avg_vid_frame_time)) {
+       //  sh_video->frametime=(float)asf->avg_vid_frame_time;
+       //  sh_video->fps=1.0f/sh_video->frametime;
+        //} else {
+       //  asf->avg_vid_frame_time=0.0; // only used for dvr-ms when > 0.0
+       //  sh_video->fps=1000.0f;
+       //  sh_video->frametime=0.001f;
+        //}

is ugly. why don't you simply remove those lines?

>  
>
>>This approach works well for all the examples I have as long as the
>>user doesnt seek too early  - ie before an accurate average has been
>>calculated. Once a seek is performed we no longer know the frame
>>number and so cant calculate the average frame time. There may be ways
>>to improve upon this and I'm open to suggestions.
>>    
>>
>
>Try printing out avg_vid_frame_time and vid_frame_ct for each frame and
>then graphing them.  That should give you a good idea of how long it takes
>to converge on the correct value.
>
>If there is a seek before this occurs, reset the averager to the current
>frame and start over (you could try to keep the data already collected, but
>it doesn't seem worth the trouble).
>
>It would look something like this:
>
>if (asf->vid_frame_ct == -1) {
>    // Seek has reset averaging data, this frame is new start point
>    asf->start_time = time;
>    asf->vid_frame_ct = 0;
>} else if (asf->vid_frame_ct >= 0) {
>    // Estimate average frame time by dividing the total time between our
>    // averaging start frame and this frame by the number of frames.
>    // If each frame time has an maximum error of e, then the max error
>    // of the estimate is 2 * e / vid_frame_ct.
>    asf->vid_frame_ct++;
>    asf->avg_vid_frame_time = (time - asf->start_time)*0.001/asf->vid_frame_ct;
>}
>// else, avg_vid_frame_time is already estimated, do nothing
>
>And in the seek function:
>
>if (asf->vid_frame_ct < XXXX) {
>    // Not enough frame to have an accurate estimate of average frame time
>    asf->vid_frame_ct = -1;  // -1 == start over
>} else {
>    // Estimate is good enough, don't bother calculating a new one
>    asf->vid_frame_ct = -2;  // -2 == finished estimating
>}
>
>For extra credit, keep using the old average after a seek until the new
>average is based on more samples than the old one.
>  
>

in any case remember that the reordering of frames (in decoding order)
will always lead to slightly wrong average results (because bframes n 
and n+1
with timestamps tn and tn+1 will have a timer < tn-1 corresponding to the
preceding [ip]-frame), so you should eventually update time only when
the timestamp of the current frame is > time (assuming that timestamps
in asf don't reset)