[xine-devel] Re: frame skipping problems [was: time effects in xine]

[Miguel F. <mi...@ce...>]

Hi,

moving this thread back to xine-devel...

On Sun, 2003-12-14 at 12:00, Artem Baguinski wrote:
> in the last weeks i've read xine sources alot and get a better feel how
> one's supposed to use it [i hope]...
> 
> On Tue, Dec 02, 2003 at 11:37:46AM -0200, Miguel Freitas wrote:
> > > i guess the smoother playback speed control could be possible if i could
> > > say to the demuxer: your step now is 1.5 frames and now 2 frames etc.
> > > then on higher speeds the decoder and video output plugins won't be
> > > trying to achieve impossible frame rates and the video queue won't be
> > > discarded that often and the video will seem play smoothly and all...
> > 
> > I don't think that would be a general solution: some demuxers don't know
> > anything about frames, they only deliver data to decoders. and even the
> > ones who understand frames, may not know about which frames can be
> > skipped or not (some frames depend on the previous frame to be decoded).
> 
> i agree now.
> 
> > > of course the "normal" players don't need this feature and i could
> > > implement it so it won't interfere with default behaviour as it is now.
> > > the only question to xine-gurus is are my ideas correct or is there
> > > a better way to do what i want?
> > 
> > if i understood correctly, you just want to drop frames more "smoothly",
> > right?
> > 
> > i suggest you to check the frame dropping mechanism in xine.
> > 
> > http://xinehq.de/index.php/faq#DISCARDEDSKIPPED
> > 
> > when trying to enqueue a frame for displaying, the decoder is told about
> > the approximated number of frames that should be skipped to recover.
> > most decoders just skip the next one and try again. you might try doing
> > experiments with some more aggressive skipping (like skipping the next X
> > frames)...
> 
> i made some experiments with heavy movies [and somewhat similar with normal
> movies under heavy CPU load], the decoder sometimes can't recover at
> all, i guess what happens is it skips one frame, the next one takes too
> long to decode anyway and it is to told to skip again and is too late
> again... under some circumstances [heavy CPU load and heavy movie and
> not the fastest machine out there] it fails on normal speed, so it's not
> my weird application's problem anymore, but frameskipping in general, i
> guess.
> 
> yep you're right if it was skipping X frames it could recover, but how
> to determine the right 'X' ?


the estimated number of frames to skip is returned by frame->draw().


> i think if it was possible to measure current frame processing
> statistics, like how long does decoding-postprocessing-displaying takes
> for a frame decoder could approximate amount of frames to skip better.
> actually what it could approximate is when the current frame will reach
> the video_out and figure wether it'll get there on time or not => does
> it make sence to decode it. all this will be heuristic but i believe
> it'll give better results. 
> 
> if you could advise me what's the best way to measure this time
> interval i could try it out and report if the approach helps.

if you want to do that, i guess you will need to measure the time within
the decoder. note however, that xine is multi-thread, measuring time
something takes to execute doesn't mean the cpu time was actually spent
there (this is also false if you are running some other application on
your system)

so, while i wouldn't take that route myself, feel free to do your
experiments and share the results with us! ;-)

regards,

Miguel