[MPlayer-users] mplayer and autom. frame rate adaption

Sebastian Ewert ewi-news at gmx.de
Sun May 29 22:16:00 CEST 2005


Hi,

I just switched from Windows to Debian a few weeks ago and I am still trying 
to get the things working as I know them from windows.

Under Windows I used a Direct Show Plugin called ReClock 
(http://reclock.free.fr/). This filter (licenced under GPL) had esspecially 
one function:
Eliminate all jerkyness from playback, that itn't caused by too high cpu 
usuage.

One can see the effect especially on slow horizontal or vertical panning 
scenes: The camera moves slowly over the horizon and in between a short jump 
and then the movement is smooth again.

ReClock eliminated this by two methods:

Method 1.) adapt the framerate
========================
Example:
Given: A movie with film framerate (23,97 fps) is played on a PAL TV (50 Hz 
interlaced). So in 1 second shall ~24 images produce an output ot 25 pictures 
=> not possible smoothly => jerkyness

Solution: Speed up the film to match a multiple of the output frequency:
23,97 -> 25 fps. This is ~4% faster and the human mind does not really 
perceive this; all professional Film -> PAL conversions are made like this 
(reason why european film are always ~4% shorter).

Problem: Lets say the sound has a sampling rate of 48kHz. After Speedup: 
25/23,97 * 48000 = 50063 samples that have to be sent to the soundcard in each 
second. Such a samplerate is usually not supported by sound card drivers.

Solution 1: leave out same audio samples => bad idea in terms of quality
Solution 2: Resample the audio on the fly to the original samplerate

Method 2.) adapt the reference clock
============================
Adapting the frame rate wasn't enough, so: 
As in most AV Playback systems Direct Show synchronises the video to the audio 
reference clock and not the other way. This produces a second source of 
jerkyness:
Because audio video have to be kept in sync it happens that the video is just 
about to display (a vsync happens) but has to wait for the sound because the 
sound is a microseond behind or after the video time. But the video can just 
be updated during the vsync. So the same picture has to be displayed twice.
That is clearly visible as jerkyness in horizontal or vertical panning scenes.

Solution: ReClock measured the reference clock and vsync times with ultra high 
precision through DirectX interface and additional probing and adjusted the 
timings with that values so that this situation can not happen. The author 
called this something like micro adjustment and resulted in adaptive 
resampling that is not perceivable by the human ear. For example the sound is 
resampled with 50048 samples -> 48000 Khz to slow down the sound (instead of 
always using fixed 50063 samples as above) or 50075 to speed it up.


Of course 23,97 -> 25 was just an example. The author of Reclock implemented 
it like this:
If movie fps differs less than 5 % from the smallest divisor of the output fps 
that is bigger than the movie fps then the adaption takes place (or something 
similar to this idea).

For example:
Monitor framerate: 75 Hz
Movie framerate: 23,9
Smallest (integer) divisor of 75 that is bigger than 23,8 : 25
(25 - 23,8) / 23,8 ~= 4,6% => adaption takes place


My question regarding mplayer:
========================
Is something like method 1 or method 2 already possible in mplayer? I found 
the -fps switch but that does not touch the audio and I found nothing else in 
the documentation.

Thank you very much in advance (and please excuse the lengthy mail)




More information about the MPlayer-users mailing list