[MPlayer-dev-eng] [PATCH] further dvr-ms playback improvements
Nico Sabbi
nicola_sabbi at fastwebnet.it
Thu Sep 28 00:05:43 CEST 2006
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)
More information about the MPlayer-dev-eng
mailing list