Summary: Tested on Windows 7 x64 and Ubuntu (single core
1 GHz, 1 GB RAM). Disabling seeking means that FFmpeg OD
imports are now:
* consistently up to 20% faster than normal FFmpeg
* consistently complete even if interacting with the import
* free from crashes when aborting and re-importing.
There is a downside with seeking disabled that if you apply
an effect before the selection is computed, the selection
will be permanently silenced for that import.
ATM I would prefer to disable seeking for 2.0.1 rather than
have it seemingly unstable and unsatisfactory on Windows
(and generally on slow single core machines).
More details below.
| From Michael Chinen <mchinen@...>
| Tue, 12 Jun 2012 02:38:21 -1000
| Subject: [Audacity-devel] [PATCH] FFmpeg on-demand based input
> Thanks everyone for testing.
> On Tue, Jun 12, 2012 at 12:07 AM, Gale (Audacity Team)
> <gale@...> wrote:
> > "Vaughan Johnson" wrote:
> >> Thanks for that, Gale. I haven't found time to test it, but good that
> >> others now have the opportunity. I think this should probably go into
> >> 2.0.1.
> > I tested again (but still only on Windows so far), this time using the
> > Win-nightly.
> > I'm afraid I have the same reservations about speed and stability. I still
> > find
> > that only in a minority of occasions can I seek or edit while waveform
> > calculation
> > is in progress, then have the calculation complete. For example I've been
> > waiting
> > five minutes now on 70% CPU for audio from an hour-long VOB file stored on
> > the
> > hard drive to complete OD-calculation, having tried to seek in a few places
> > in
> > the waveform.
> Ok, I didn't see this in linux or mac, but maybe windows is more
> sensitive. It's also possible the ffmpeg version is different.
I am using 0.6.2 from here:
> > It's still quite easy to crash if I File > Close on a stalled FFmpeg On
> > Demand
> > import I was interacting with, then try to FFmpeg On Demand import again,
> > and repeat those steps a few times.
> Good catch, thanks.
> > If I just let that hour-long VOB file complete OD import, I see wide
> > variations
> > in time taken at each attempt, from 35 seconds to 90 seconds, usually about
> > 70 seconds. Normal FFmpeg import is a reliable 20 seconds.
> Thanks, I need to look into this.
> > Same story with an hour long WAV file. On-demand using libsndfile is always
> > about 15 seconds. FFmpeg on-demand varies from about 50 seconds to
> > 90 seconds (if I leave it alone).
> I expect it to be much slower here since ffmpeg is copy in vs od
> libsndfile is aliased.
OK, I did not realise at the time that this was copy-in.
> > Should we try it without seeking/interacting with the import? And given
> > we are able to seek/interact, can you explain a bit more about what
> > "background" on-demand loading means (as written in the Libraries
> > Preferences)? It would be good to know for the Manual.
> This is normal on demand (loads in the background, but use can demand
> different parts to be loaded). I guess users won't know what is meant
> by just on-demand.
Thanks. I agree "on-demand" will not mean much. I am not sure if
"background" is the best word as the user will see the waveform
as it is computed.
Possibly "On-demand loading (faster)" might be better (analogous
with "read directly (faster)" in the Import / Export Preferences).
> Here is a patch that disables seeking, please apply it if that
> eliminates the crashes/waveform stalls.
> I will test more on mac/linux to see if I can get these issues. If
> not, maybe I'll add a subcheckbox for seeking after 2.0.1
Thanks. Tested on Win 7 and Ubuntu 12.04. Definitely, FFmpeg-OD
import times are now consistent.
It's now about 20% faster to import audio files when letting
FFmpeg-OD complete than when using normal FFmpeg. If importing
audio from video it's a few % faster, I would say.
If I try to play or edit where the waveform has not yet been
computed, this slows down completion but does not stall it, and
I don't see crashes on repeated aborts using File > Close then
There is a problem though if user drags a selection and applies an
effect before the waveform has been computed. This will silence
the audio or render it as dither noise.
If I then undo the unwanted effect before the calculation has
completed, OD is stalled permanently. This is also true when seeking
is enabled (as in HEAD) and the effect does what is intended.
Libsndfile OD doesn't display this problem - probably a P3?
If I undo the unwanted effect after calculation has completed,
the selection reverts to uncomputed state, as it does if I undo
and redo import. So I see no way to get the audio back except by
File > Close and repeat the import.
I have since found that merely seeking then playing files over
30 minutes long often stalls FFmpeg OD in HEAD, not only on
Win 7 dual core but also on Ubuntu 12.04 on a basic netbook
(1 GHz, 1 GB RAM). So I guess disabling seeking is less bad than
what we have in HEAD. Disabling seeking shows the intended
speed improvement rather than slowdown, no crash risk and
generally the calculation completes.
Either left "as is" or disabling seeking, I think there would have
to be a release note on the behaviour, but I have said in the
Manual that you can edit or play when the waveform appears
(which is going to be good advice either way). The Status Bar
"Click to change task focal point" should probably not appear
if we are disabling seeking.
I have not had time to test reopening projects hat have not
been fully imported. Tests welcomed.
One other issue - another VOB I tried to import from my hard
drive seems to have multiple streams, but OD FFmpeg import
only imports the first stream. Normal FFmpeg import imports the
complete audio. Possibly P4.