[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