[MPlayer-dev-eng] PTS system broken..

[Charles Henrich]

> > So what happens is the duplicate code goes something like, "hey as long as
> > there is a difference, duplicate a frame".  So it checks the difference
> > (.40001 - .40) and behold, there is one.  but in reality, there isnt.  So
> > a duplicate frame is (incorrectly) inserted.
> nope.  there are limits to be beaten, and float errors never will even be
> close to this limit. currently the limit is 2 frame times, but float value
> never will reach error 0.08...

That actually happens.  I can show you the code, I found it by watching it go
"Addding a duplicate frame" in exactly the above case.  At frame #213, it
*always* adds a dup frame, and then does so again, *every* second at exactly
the .52 marker.  The skips go willy nilly to.  And in the PAL case its easy
(1/25 = .04) NTSC, we get 1/30 which is .333333333333 infinity.  God knows
what will happen in that case?

frame_time out of video_read_frame is .040001 instead of .04.  So
sh_video->timer is now off, and v_timer_corr is way off as well.  Where
it is supposed to be zero, it ends up .000001  causing an errant duplicate
frame:

    in_size=video_read_frame(sh_video,&frame_time,&start,force_fps);
    if(in_size<0){ eof=1; break; }
    sh_video->timer+=frame_time; ++decoded_frameno;
   
    v_timer_corr-=frame_time-(float)mux_v->h.dwScale/mux_v->h.dwRate;

So we get a duplicate frame every second, skewing audio sync immediatly..

> they are done with integers. the float values are just temporary numbers and
> never will affect a-c sync or frame drop/skip.

Where?  The skip/dup correction is all float based ??

-Crh

       Charles Henrich         Eon Entertainment         henrich at msu.edu

                       http://www.sigbus.com:81/~henrich