[MPlayer-dev-eng] [PATCH] ffw-av - interactive fastforward/slow with audio speed adjust (1st draft)

[Arpi]

Hi,

> Here is a first attempt at a live interactive fast/slow-forward patch

> Caveats:
> 
> 1.
> Not all sound drivers can accelerate the sound speed past a certain
> sample rate.  Some also hold back the video speed.  (For example,
> alsa9 on my system on certain divx files limits the playback rate to
> 1.0.  However, the OSS emulation of my alsa driver does not suffer the
> same problem...  The divx5.0 files from www.redvsblue.com
> exhibit this behavior, for example.)


it's driver (or ao_*.c) problem.
anyway, oss driver for emu10k1 (sb live) allows setting 192000 hz,
but it doesnt play at that rate, so its clearly a driver bug.
(i guess an off-by-one type, as 191999 hz works and 192001 isn't
allowed to be set)

> One can sort of work around this by specifying "-aop list=resample" on
> the commandline.  This causes the speed modifications to apply to the
> resample audio plugin, and therefore uses more cpu but can have a
> wider range of possibilities.  It also will not limit the video
> playback rate as far as I've seen.  However (this is a big however!)
> increasing or decreasing the speed too much can cause the A-V sync to
> go very out of control.  Using "-mc 10" can slightly alleviate this
> problem, but only to a certain extent (about 5x on my 1.3 ghz tbird).

for speedup, it's normal, even my p4 is too slow sometime sto handle
-speed 5 or above. for slowdown, it should work in sync, unless
fps is so low that frame_duration is longer than audio buffer length.

> 2.
> Changing the speed rate can cause minor jumps in the video file.  On
> some files (notably quicktime and wmv), the movie is sped up for a
> short moment so that you miss a half second or so, regardless of
> whether you're slowing way down or speeding way up.
> 
> Note that this phenomenon occurs when pausing and resuming in normal
> speed playback as well, so I'm thinking this could be limitations with
> the individual codecs' demuxers rather than with the way I
> reinitialize the sound.

no, it's a problem of audio buffering, ie. audio preload.
in normal case, audio is around 0.3 .. 1.5 secs (depending on samplerate,
driver/soundcard type, buffer size etc) before the video, as you have
same amount of audio delay caused by drivers and buffering.

when you pause, or reset audio, you suddenly lost the buffer content,
so new audio samples will be 0.3 .. 1.5 secs behind the video, so the
video playback will be speed up (or wiht framedrop, just skipped) to
get a-v sync back.
to workaround this, ao drivers may implement pause and resume without
dropping the buffer content (some apis, like OSS support that).

> 3.
> Using a very low speed can make mplayer very unresponsive, since
> mplayer can only accept one command per rendered frame...

check int frame_time_remaining flag and related ifs:

        // delay = amount of audio buffered in soundcard/driver
        if(delay>0.25) delay=0.25; else
        if(delay<0.10) delay=0.10;
        if(time_frame>delay*0.6){
            // sleep time too big - may cause audio drops (buffer underrun)
            frame_time_remaining=1;
            time_frame=delay*0.5;
        }

this code will limit time spent before 2 event checking, to
workarould unresponsiveness and audio stuttering for low fps video.
as delay is in movie spave, not in real time (afair), you may have
to multiply (or divide?) delay*0.6 by playback_speed too in the if() and
bellow in time_frame=delay*0.5;.


> 4.
> The speed display at the end of the status display line only appears
> when both audio and video are being played, but I'm not sure this
> field is good anyway since it easily puts the line length at more than
> 80 characters.  Regardless, I can easily add it to the
> audio/video-only lines if anyone is interested.  Another option would

sure

> be to make it display the speed only when it is not 1x (which I kinda
> like best, actually...)

yes, i vote for this
also you could display speed (when != 1.0x) on the OSD, for osd_level>=1

> Anyway, I hope people find it useful, and I hope to get it to a point
> where it can be included in mplayer.  After writing the bulk of the

I want it to eb in CVS, so if you can fix the above issues, and we'll
find the patch clean (no unacceptable ugly hacks) it's ok.

> patch, I discovered the following thread in the archives, so I'm
> hoping there's still a bit of interest:
> 
> http://mplayerhq.hu/pipermail/mplayer-dev-eng/2003-February/015835.html

:)

there were soem tries to implement runtime speed changes, but none
of them handled audio correctly so they were refused...


A'rpi / Astral & ESP-team

--
Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu