Re: [xine-devel] time effects in xine

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

hi,

On Tue, 2003-12-02 at 08:01, Artem Baguinski wrote:
> hello
> 
> i'm a new subscriber of the -devel and i'd like to find my way in the
> project before i start contributing to it ;)
> 
> my area of interest is realtime video [as well as other media]
> processing and i often use libxine in my projects. i must admit, its api
> is one of the cleanest apis i've ever encountered, especially in the
> open source video related projects.

cool, thanks! ;-)


> among thei controls of the video player is playback "speed": we wanna be
> able to control the playback "smoothly" from frozen-frame through
> original speed to, say, 3-times the original speed. and this is the first
> control that we have some problems implementing. at the moment we use
> "xine_set_param(stream,XINE_PARAM_SPEED,speed);" and i works well with
> low speeds but becomes jerky with high speeds. as i can figure from
> sources "smooth" fast playback wasn't meant to be implemented in
> libxine, demuxer for example doesnt have a clue when the speed changes
> and provides frames sequentially to the video queue even when video out
> has no chance to play them all back (or decoder has no chance to decode
> them on time). 
> 
> 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).


> 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)...

regards,

Miguel