| From Benjamin Drung <bdrung@...>
| Thu, 20 Sep 2012 00:50:01 +0200
| Subject: [Audacity-devel] building audacity with ffmpeg 0.11.1 - started patching ...
> Am Mittwoch, den 19.09.2012, 23:05 +0100 schrieb Gale Andrews:
> > | From Benjamin Drung <bdrung@...>
> > | Wed, 19 Sep 2012 14:18:39 +0200
> > | Subject: [Audacity-devel] building audacity with ffmpeg 0.11.1 - started patching ...
> > > Am Freitag, den 14.09.2012, 22:38 -0700 schrieb Gale (Audacity Team):
> > > > "Benjamin Drung-2" wrote:
> > > > Am Donnerstag, den 13.09.2012, 21:38 +0100 schrieb Gale Andrews:
> > > > >> Isn't trying to leverage ffmpeg.exe the better option? The Audacity
> > > > >> command-line exporter never seems to have an issue using latest
> > > > >> git FFmpeg even on Windows.
> > > > > I am against using the command-line exporter if the library usage is
> > > > > removed.
> > > > The suggestion (which has been made before on this list) was that users
> > > > would still be able to import and export as now using the import and export
> > > > dialogues and the export options, but we'd be using whatever version of
> > > > ffmpeg.exe or equivalent the user happened to point Audacity to, in the
> > > > hope of freeing ourselves from most of the FFmpeg version headaches.
> > > >
> > > > I imagine the Libraries Preferences could still be used to choose the
> > > > ffmpeg.exe version.
> > > >
> > > > Do you feel any happier with that?
> > >
> > > No. The idea of using the command-line tool seems to me like adding an
> > > additional layer that brings new problems while solving one.
> >
> > It's suggested as a replacement for the dynamic libs, not additional.
> >
> >
> > > Besides the slower export
> >
> > That remains to be proved, though it would be a major objection
> > if proved.
Further to Steve's test I did my own test on Windows 7 x64 using
FFmpeg version SVN-r26400 (somewhere before current FFmpeg
0.8 release).
This machine is 2.4 GHz Dual Core 6 GB RAM, so more capable than
the one I used to test before. Over three tests with a five-minute
stereo track, using identical format options, AAC, WMA and AC3
export takes the same time or a little less using (external program)
than the specific encoding option such as "AC3 Files (FFmpeg)".
> > > the progress UI these topics came to my mind:
> > >
> > > 1) How do you handle errors? You need to parse the textual output of
> > > FFmpeg, which can be everything.
> >
> > Users will not be entering command-line strings, rather their "Options"
> > settings for the format will determine what gets passed to the
> > encoder. So a) there should not be many errors and b) other GUI
> > apps that use FFmpeg.exe seem to manage to throw a sensible
> > error if open or encoding fails.
>
> Does these other GUI apps just pass the error message from the
> FFmpeg.exe to the user? Using the library gives you a tighter control
> about the error messages.
Given the error text, my feeling is these are not literal errors
parsed "as is" from FFmpeg.exe.
> > I'm not supposing this suggestion is other than a lot of work,
> > but Leland's initial reaction was that this was feasible.
> >
> > The potential prize for saving of work in the long term seems quite
> > significant to me.
>
> Supporting newer FFmpeg version at compile time shouldn't be that time
> consuming. Supporting a different range at runtime may be more
> complicated.
Isn't it actually quite a lot of work to keep updating for current
FFmpeg while still keeping backwards compatibility (bearing in mind
Windows and especially Mac recommended FFmpeg may be many
versions behind)?
> I tend to thinks about offering my help in maintaining the FFmpeg
> support in Audacity.
Thanks of course for your help.
> > While we are at it, we could use FFmpeg for MP3
> > exports so that users only have to download one optional library.
>
> Using FFmpeg for MP3 export is orthogonal to this proposed change.
Yes we could drop LAME support now (with a certain amount of
work).
However if we do the proposed change, doesn't it make sense to do it
for only one library?
> > Even the Windows and Mac users are starting to complain that
> > the recommended download of FFmpeg for use in Audacity is
> > years out-of-date.
>
> Where is the difference to the proposed change? The user will still have
> to download FFmpeg.
The difference is that the user could use an arbitrary version of
FFmpeg (maybe a version they already had obtained in another
program, so they don't need to download a different version at
all).
It means that Windows / Mac users (on which platforms we may
not have resources to update the recommended FFmpeg version)
are not compelled to always use older versions.
We lose the potential problem that Windows/Mac holds back the
latest FFmpeg version that Audacity can use.
Gale
|
