[MPlayer-dev-eng] PTS system broken..
Charles Henrich
henrich at sigbus.com
Thu Feb 28 23:39:08 CET 2002
> > 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
More information about the MPlayer-dev-eng
mailing list