ffmpeg import/export not working with ffmpeg version in maverick

FFmpeg libraries or packages built in 2010 will not be recognised by Audacity
(Help > Show Log will show "undefined symbol: match_ext").

FFmpeg libraries built after June 1st 2010 will prevent Audacity compiling.

See Release Notes for details. Simply fixing for 2010 builds of FFmpeg will
break 2009 builds, yet we want some backwards compatibility. Can the code
support 2009 and 2010 with some kind of runtime detection of the FFmpeg version
in use?

Created an attachment (id=54)
Patch by Tim Harder to detect FFmpeg versions from 2010

Tested attached patch from Tim Harder. Success on Windows 7. Audacity
recognises FFmpeg 20 July 2009 from the FFmpeg-for-Audacity installer.

On Ubuntu 10.10, Audacity cannot find the installed ffmpeg 4:0.6-2ubuntu6
library containing libavformat.so.52.64.2 (Unicode release, standard configure
FFMPEG: using LOCAL libraries). Help > Show Log shows "undefined
symbol:match_ext", so Audacity seems not to have picked up the FFmpeg version
correctly. However hardcoding for "av_match_ext" as per Release Notes does
allow Audacity to find FFmpeg.

The current situation seems thus for most people. If you self-compile FFmpeg
greater than 0.5 and point 1.3.13 to it, Audacity either:

* does not recognise FFmpeg
* recognises FFmpeg with errors which may lead to repeatable segfaults
* appears to recognise FFmpeg but can't recognise valid files on import

On Ubuntu 10.10 if I point 1.3.13 (compiled with default ./configure that
produces "use ffmpeg=local") to the Synaptic-installed Ubuntu FFmpeg package,
1.3.13 seems to fully recognise FFmpeg and works properly without crashes.
(Steve does get intermittent crashes in that scenario importing WMA or AC3
files which had been exported by 1.3.12).

I just confirmed my results by reinstalling Ubuntu 10.10, and rebuilding
Audacity with default ./configure against Nikola's av-match-ext patch
(http://forum.audacityteam.org/download/file.php?id=2253). If I then recompile
Audacity with default ./configure against the attached bug 176 patch, I'm back
to Audacity not recognising FFmpeg with the "undefined symbol:match_ext" error.

Discussion at http://forum.audacityteam.org/viewtopic.php?f=18&t=39251

The patch attached to bug #233 is a superset of (= contains) the patch from
comment 1.

Benjamin,

So where are we now? We have your patch attached to bug 233 which appears to
work on Ubuntu using the Ubuntu-distributed FFmpeg (leaving aside the WMA
crashes in Bug 274 and possible licensing issues from build-time linkage). I
and a couple of other people could never make the patch attached to this bug
work on Ubuntu when self-compiling FFmpeg and building Audacity with default
./configure. There was always "undefined symbol:match_ext" error when loading
FFmpeg from Preferences. The patch did not cause a problem on Windows -
Audacity still recognised the libs from the FFmpeg installer we supply.

However we still have the previous reports
(http://forum.audacityteam.org/viewtopic.php?f=18&t=39251) where people loading
latest FFmpeg from Audacity Preferences found Audacity does not recognise
legitimate FFmpeg-supported files on import, showing "av_open_input_file()
failed" in Help > Show Log. I assume your patch attached to bug 233 will not
address that if you do not set USE_SYSTEM_FFMPEG. What happens in your bug 233
patch if user uninstalls Ubuntu's FFmpeg or otherwise sets SVN FFmpeg as the
system FFmpeg, then sets USE_SYSTEM_FFMPEG? Is there some way you can test such
a scenario? If FFmpeg files are not recognised in that case then it seems we
need a new bug for that.

Fixing bug 176 but not bug 233 seems less controversial to me. If we are going
to address 233 at all it would "seem" more convenient to address 176 by
applying the bug 233 patch, but might it be safer to separate them anyway?
I have more comments in bug233#c11 .

> I assume your patch attached to bug 233 will not
> address that if you do not set USE_SYSTEM_FFMPEG.

The patch should work with newer FFmpeg version regardless if USE_SYSTEM_FFMPEG
is set or not.

> What happens in your bug 233 patch if user uninstalls Ubuntu's FFmpeg

Nothing if Audacity was compiled without setting USE_SYSTEM_FFMPEG. Audacity
would crash on startup if the is no other FFmpeg version installed which is
binary compatible if Audacity was compiled with USE_SYSTEM_FFMPEG.

When the audacity Ubuntu package is compiled with USE_SYSTEM_FFMPEG, it will
depend on the FFmpeg packages. If you uninstalls Ubuntu's FFmpeg, it will
uninstall audacity too.

> or otherwise sets SVN FFmpeg as the system FFmpeg,

How do I do that? Compile with ./configure --prefix=/usr?

> then sets USE_SYSTEM_FFMPEG? Is there some way you can test such
> a scenario? If FFmpeg files are not recognised in that case then it seems we
> need a new bug for that.

Do you want me to install SVN FFmpeg and then compile Audacity with
USE_SYSTEM_FFMPEG against it?

(In reply to comment #6)
> Do you want me to install SVN FFmpeg and then compile Audacity with
> USE_SYSTEM_FFMPEG against it?
Benjamin,

I'm really just trying to find out if we need to start a new bug for a problem
with Audacity apparently recognising SVN FFmpeg but then giving an error
dialogue in the GUI when importing FFmpeg files. That is, is the problem
specific to latest FFmpeg builds, but doesn't occur with a build from a bit
earlier like the current Ubuntu FFmpeg? Or is it to do with how Audaoity has
been configured?

Three people on the Forum including me, and a couple of others I know of get
"av_open_input_file()failed" in the log when the import failure happens with
SVN FFmpeg. Steve gets "Failed to retrieve file times for '/nyquist worker/'
(error 2: No such file or directory), Error: can't open file '/nyquist
worker/'" when using SVN FFmpeg. Steve's issue could possibly be some conflict
with Nyquist Workbench. Steve's and my problems go away when using the Ubuntu
FFmpeg (except for the WMA and AAC export problem).

So it would be great if you (who knows more what you are doing :=) could
install SVN FFmpeg and compile Audacity with USE_SYSTEM_FFMPEG.

Steve and I were compiling with default ./configure and the configure output
was showing "using SYSTEM libraries" for FFmpeg. I can't find out what the
other four people were doing exactly.

If local libraries are used instead of system, is that for the case where you
link to a library version you have not installed? If so, how do you configure
Audacity to the correct path for the local library?

I have installed SVN FFmpeg and compiled Audacity with USE_SYSTEM_FFMPEG. It
compiled (which means that all required functions are available) and Audacity
gave me the options to use FFmpeg for exporting audio, but here's the sad part:
Importing and exporting through FFmpeg failed. In the log I found this:

Export ac3 file:
Error: can't open file '/' (error 21: is a directory)
Error: FFmpeg: ERROR - Can't open output file "/home/foo/bar/baz.ac3" to write.
Error code is -2.

Import mp4 file:
Opening with libav
Error: can't read from file descriptor 20 (error 21: is a directory)
Error: av_open_input_file() failed for file /home/foo/bar/baz.mp4
Error: Importer::Import: Opening failed.

I will give a full explanation how I compiled everything in the forum:
http://forum.audacityteam.org/viewtopic.php?f=18&t=53227

Moved "importance" to "repeatable".

Created an attachment (id=113)
Provides support for later versions of FFmpeg

This patch provides support for the more recent versions of FFmpeg. It still
supports for the existing pre-built Windows and Mac FFmpeg binaries. It also
incorporates the fix for bug #274 and provides compile-time verification of
FFmpeg function call prototypes.

Only tested so far on Ubuntu 10.10. Ubuntu-distributed FFmpeg is listed on
opening Prefs on initialised or non-existent .cfg.

Should be tested with self-compiled FFmpeg.

Side issue for discussion: although FFmpeg version number is listed in Prefs,
when you click "Locate...", then "Yes" in "Success" to open "Locate FFmpeg",
you do not see the path to the libs, only "libavformat.so.52". On Windows, once
you have installed FFmpeg in an expected location and the version number is
listed, the path is shown in "Locate FFmpeg".

See bug 141 comment 3 - undefined symbol match_ext in HEAD after running 1.3.12
Ubuntu package.

Also see bug 313 comment 1. Import of any formats (even non-FFmpeg) is
generally flaky after applying the patch in comment 10 here. WMA imports will
always
segfault, but so will WAV, MP3 and FLAC imports (most, but not all of the
time). I have to suspect this patch in comment 10, because:

* If I use the 1.3.12 Ubuntu-distributed Audacity, which is using the same
Ubuntu-distributed FFmpeg as my HEAD version, I can import WAV and MP3 reliably
without segfaults;

* Having used 1.3.12, this disables FFmpeg in HEAD, after which the problem
with WAV and other non-FFmpeg imports goes away.

I tested the patch from comment 10 with the system FFmpeg and it works on my
system.

Exporting and importing ac3, flac, ogg, wav, wma worked.

ogg imports and exports are very slow (bug #311).

The m4a export produces a file containing only silence. Should I open a new bug
report for it?

System: Ubuntu 11.04 (natty) development version
Audacity: trunk configured to use all system libraries

(In reply to comment #14)
> I tested the patch from comment 10 with the system FFmpeg and it works on my
> system.
> Exporting and importing ac3, flac, ogg, wav, wma worked.
> System: Ubuntu 11.04 (natty) development version
> Audacity: trunk configured to use all system libraries

Hmm. Is this the Ubuntu FFmpeg or SVN FFmpeg? It should be tested against
self-compiled SVN FFmpeg too.

Anyone else see the import problems I have (Per, Steve)? The patch seemed to
apply cleanly and I did make clean, then ./configure; make dep; make. So some
local libraries used.

All else I can do is a fresh checkout and patch that.

> The m4a export produces a file containing only silence. Should I open a new
> bug report for it?
Now done: Bug 317.

> Is this the Ubuntu FFmpeg or SVN FFmpeg?

It's the Ubuntu FFmpeg package.

Gale, are you still having issues with the patch? It really should affect
anything other than FFmpeg files. Could you try it against a fresh checkout?
Also, did you happen to a "make dep" in the "src" directory before/after
applying? (would be a good idea to do it.)

Leland

(In reply to comment #17)
> did you happen to a "make dep" in the "src" directory before/after applying?
>(would be a good idea to do it.)
As per comment 15 I applied the patch then did make clean, then ./configure;
make dep; make. Did not do "make dep" before the patch (except that I did it
before my previous make). This was as per
http://wiki.audacityteam.org/wiki/Developing_On_Linux_Under_Windows#Modifying_Audacity
which I understand to be Richard's advice, but sounds like we should follow
your suggestion too.

(In reply to comment #14)

Confirm that it builds ok with system FFMpeg on Ubuntu 10.10
An import WAV, MP3 and FLAC with FFmpeg, but importing WMA segfaults.
Can export WMA successfully (Bug 274)

(In reply to comment #19)
> builds ok with system FFMpeg on Ubuntu 10.10
> (c)an import WAV, MP3 and FLAC with FFmpeg, but importing WMA segfaults.
Have you tried the patch in bug 317 for FFmpeg import crashes? That needs to be
applied on top of the patch attached here.

Okay, I'm getting kind of confused. Is this working for anyone at all? Should
I regenerate the above patch with the fix from bug #317? What are the
outstanding issues?

Leland

For those experiencing slow exports after importing an OGG file, can you try
changing "Edit->Preferences->Import/Export->Read uncompressed..." to "Make a
copy..." and then exit Audacity, get back in, and try to reproduce the
slowness.

For me, it no longer occurs. And since the slowness happens with OGG -> OGG as
someone else mentioned somewhere (yes...I'm still confused ;-)), it doesn't
have anything to do with FFmpeg, so this should probably be a different bug.

Leland

Leland wrote:
> Should I regenerate the above patch with the fix from bug #317?
Yes, I think that would make it easier for others to test.

> What are the outstanding issues?
All FFmpeg bugs "should" have the "FFmpeg" keyword:
http://bugzilla.audacityteam.org/buglist.cgi?keywords=FFmpeg&resolution=---

though that will be wider than operational issues with FFmpeg > 0.5.

I think different people may have different issues but I'll be testing soon
with this patch + bug 317 patch with Ubuntu FFmpeg and reporting back. I
suggest we could use the "Steps to Repro" here as a summary of operational
issues with FFmpeg with the relevant bug number listed.

We must also test against SVN FFmpeg which could have its own issues. I will
"try" and do that later. All the tests so far have been done against the much
earlier Ubuntu 10.10 FFmpeg AFAIK (though Benjamin might have a later FFmpeg
with Ubuntu 11 devel version).

> For those experiencing slow exports after importing an OGG file, can you
> try changing "Edit->Preferences->Import/Export->Read uncompressed..." to
> "Make a copy..." and then exit Audacity, get back in, and try to reproduce
> the slowness.
> For me, it no longer occurs. And since the slowness happens with OGG ->
> OGG as someone else mentioned somewhere (yes...I'm still confused ;-)), it
> doesn't have anything to do with FFmpeg, so this should probably be a
> different bug.
That OGG slowness thing is separate (bug 311) but I have never seen it so far.

Why would the copy-in Pref affect OGG > OGG? Audacity should copy the OGG in
irrespective of that setting.

(In reply to comment #23)
> That OGG slowness thing is separate (bug 311) but I have never seen it so far.
>
> Why would the copy-in Pref affect OGG > OGG? Audacity should copy the OGG in
> irrespective of that setting.

I'll respond in bug #311.

Leland

OK on fresh checkout and make dep before and after applying attached patch then
make dep before and after bug 317 patch, on Ubuntu 10.10 with the Ubuntu
FFmpeg...

* I seem to get consistently safe exports of AC3, WMA and AAC. However AAC
export is far too slow.

* I seem to get consistently safe imports of Audacity-exported AC3, WMA and
AAC. However the AAC imports are silenced.

* Issues with crashes importing non-FFmpeg files, loss of FFmpeg in HEAD after
running 1.3.12, and Prefs not opening at the Libraries section when saved there
seem to have gone.

TODO:

* Tests with SVN FFmpeg

* Tests importing AAC, WMA2 and AC3 files *not* produced by Audacity (both with
Ubuntu and SVN FFmpeg)

Created an attachment (id=125)
Just a combination of 0.6.1 support and the import crash fix

This is a combined patch that include the 0.6.1 support and the fix for the
import crash from bug #317.

I have been unable to pin down why M4A imports are silenced. Actually, I no
longer see this, so if y'all can attach a file to this bug that consisently
imports as silence that'd be great. Heck, if you have a mono file that imports
as stereo, please attach that as well.

One thing that I did discover is that on 2010-05-14, the native aac encoder was
updated and this caused a tremendous degradation in export quality. I do not
believe this to be an Audacity issue since the ffmpeg command produces the same
results.

Another thing is that exporting a 10 minute chirp on my system consistently
takes 22 seconds prior to the ffmpeg changes on 2010-04-02. After that date,
exporting the same chirp consistently takes 35 seconds. Again, I do not
believe this to be an Audacity problem since the ffmpeg command produces nearly
the same time difference as Audacity.

(In reply to comment #26)
> I have been unable to pin down why M4A imports are silenced. Actually, I no
> longer see this, so if y'all can attach a file to this bug that consistently
> imports as silence that'd be great.
For me, the same file will sometimes import as silence and sometimes not. The
silencing was happening every time after applying the 0-6-1 support and import
crash patches. After reboot, it hardly happens, but sometimes does.

> Heck, if you have a mono file that imports as stereo, please attach that
> as well.
You gonna love this. I generated a default 30s chirp in Audacity on Win 7 and
Audacity on Ubuntu. I exported with (external program) and default

 ffmpeg -i - %f

naming the file as chirp.m4a. Win FFmpeg is 0.5, Ubuntu FFmpeg is the Ubuntu
package. The ffmpeg output says it wrote a mono file. The chirp.m4a exported on
Ubuntu imports as mono into Audacity on Ubuntu, and most apps see it as mono
e.g MediaInfo, but VLC imagines it is stereo.

If I import that chirp.m4a exported on Ubuntu into Audacity on Win 7, it
imports as stereo. dBPowerAmp and MediaInfo (slightly old version) see it as
stereo. QT and iTunes see it as mono.

If I drag the chirp.m4a produced on Windows 7 into Audacity on Windows, it
imports as stereo.

If I drag the chirp.m4a produced on Windows 7 into Audacity on Ubuntu, it
imports as mono, and Ubuntu apps see it as mono (or stereo for VLC) as before.

I think you will be able to repro it on Windows (and I assume on FFmpeg 0.6.1
too, but I have not tried with 0.6.1 yet). What happens on Mac?

> One thing that I did discover is that on 2010-05-14, the native aac encoder
> was updated and this caused a tremendous degradation in export quality. I do
> not believe this to be an Audacity issue since the ffmpeg command produces
> the same results.

Agreed, but would still have to be release noted because we will be blamed
otherwise.

Or could/should we disable Audacity support for the native aac encoder via
normal "M4A files" export? I think it would send an appropriate message.

> Another thing is that exporting a 10 minute chirp on my system consistently
> takes 22 seconds prior to the ffmpeg changes on 2010-04-02. After that date,
> exporting the same chirp consistently takes 35 seconds. Again, I do not
> believe this to be an Audacity problem since the ffmpeg command produces
> nearly the same time difference as Audacity.
That is a much less significant difference than that implied by the "3 - 4
times slower" than Audacity export to other formats. Can you test on your
system:

* How much less than 35 seconds does that file take to export via LAME at the
command-line?

* How much slower is Audacity GUI export to AAC (using FFmpeg 0.6.1) than to
other formats?

I wonder (even if it is an FFmpeg issue) if Audacity is making it worse?

FWIW I tested M4A encoding in FFmpeg 0.5 versus 0.6.1 (both using libfaac) at
the command-line on Windows 7. 0.6.1 is if anything slightly faster, and no
quality issues.

(In reply to comment #26)
> Created an attachment (id=125) [details]
> Just a combination of 0.6.1 support and the import crash fix
Actually this patch lacks the three new files in lib-src\ffmpeg\libavutil

attributes.h
avconfig.h
error.h

which you will need to grab from the original patch:
http://bugzilla.audacityteam.org/attachment.cgi?id=113

Thanks Leland, I built Audacity against your v8 patch and am using FFmpeg HEAD.

WMA and AMR NB export and import OK (at least Audacity's own files).

AC3 import OK. AC3 export gives a zero byte file but the same happens with
standalone ffmpeg at the command line "LIBAVUTIL_50 not defined in file
libavutil.so.50 with link time reference". I gather I may have to find
libavcore, from Googling the error?

M4A import OK. Can't test M4A export as disabling the native aac encoder didn't
give me libfaac so I will try again later with --enable-libfaac.

(In reply to comment #64)
> AC3 import OK. AC3 export gives a zero byte file but the same happens with
> standalone ffmpeg at the command line "LIBAVUTIL_50 not defined in file
> libavutil.so.50 with link time reference". I gather I may have to find
> libavcore, from Googling the error?
>
Not sure why you got that error, but I too get an empty AC3 export. I checked
the Audacity log and found:

01:07:58: Debug: Log: [ac3 @ 0x1d26d400] Specified sample_fmt is not supported.
01:07:58: Error: FFmpeg : ERROR - Can't open audio codec 0x15003.

Apparently, on Jan 4th, 2011, the default AC3 encoder now ONLY accepts FLOAT
samples. It's the only encoder (near as I can tell) that is like this. The
only other encoder that accepts FLOAT is the PCM fella, but he accepts all of
the formats so he's not a problem.

The older encoder has been renamed to ac3_fixed. Not sure of the best
approach:

1) Make the Audacity exporter capable of supplying one of the sample formats
supported by the encoder
2) Just force usage of the ac3_fixed encoder since he's the only one like
this.

> M4A import OK. Can't test M4A export as disabling the native aac encoder didn't
> give me libfaac so I will try again later with --enable-libfaac.
Here's the parameters I'm using for the Windows and Mac builds:

    sh ./configure --arch=i386 \
                   --cc=gcc-4.0 \
                   --disable-ffplay \
                   --disable-ffprobe \
                   --disable-ffserver \
                   --disable-avdevice \
                   --disable-debug \
                   --disable-encoder=aac \
                   --disable-decoder=amrnb \
                   --disable-decoder=amrwb \
                   --disable-static \
                   --disable-doc \
                   --enable-gpl \
                   --enable-nonfree \
                   --enable-version3 \
                   --enable-libopencore-amrnb \
                   --enable-libopencore-amrwb \
                   --enable-pthreads \
                   --enable-libfaac \
                   --enable-libspeex \
                   --enable-libgsm \
                   --enable-libmp3lame \
                   --enable-memalign-hack \
                   --enable-shared

Created an attachment (id=140)
Forces usage of ac3-fixed encoder

I took the easy way out and forced usage of the "ac3-fixed" encoder.

(In reply to comment #66)
> Created an attachment (id=140) [details]
> Forces usage of ac3-fixed encoder
>
> I took the easy way out and forced usage of the "ac3-fixed" encoder.

And the easy way was (at least the way I did it) was stupid. I'll work on this
again when I get home tonight.

Created an attachment (id=141)
AC3 encoder should be detected for all versions now

Okay, this one should detect the proper AC3 codec for FFmpeg HEAD and older
versions.

Created an attachment (id=142)
Reuploading v10 patch...

(In reply to comment #69)
Thanks Leland. Will try v10. For those who try the patches one after the other,
is there an easier way to apply the patch than manually deleting then restoring
the affected files before patch? E.g. could I actually apply your v10 patch
over an earlier patch version?

(In reply to comment #70)
> (In reply to comment #69)
> Thanks Leland. Will try v10. For those who try the patches one after the other,
> is there an easier way to apply the patch than manually deleting then restoring
> the affected files before patch? E.g. could I actually apply your v10 patch
> over an earlier patch version?

No, I usually have a clean copy of audacity, delete the patched version, make a
copy of the clean version and the repatch.

You could try reapplying the patch that you had used before and it should
reverse everything, but I've never tried it.

But, I'm hoping that v10 is the last one. :-)

Leland

There are two ways:

1. Use -R to revert the previous patch (patch -R < previous.patch).

2. Use svn revert to revert the changes.

(In reply to comment #72)

> 2. Use svn revert to revert the changes.

Oooo, I like that one. Didn't know about it. I'll have to give that a try
next time.

Thanks,

Leland

Thanks for the tips, Benjamin.

Leland, I applied v10 and I exported all four FFmpeg formats using FFmpeg HEAD
and all three available formats (amr is not available) uing the Ubuntu FFmpeg.
I imported the seven files using both versions of FFmpeg.

My only issue was with the stereo m4a I exported using Ubuntu's FFmpeg so using
the native aac encoder. This is the log when importing it into Audacity with
either version of Audacity:
Error: Stream 0 start_time = 0, that would be 0.000000 milliseconds.

If I use Ubuntu's FFmpeg at the Audacity CLI with AUdacity HEAD or 1.3.12 I get
no export at all and

"/usr/bin/ffmpeg: relocation error: /usr/local/lib/libswscale.so.0: symbol
av_opt_set_defaults, version LIBAVUTIL_50 not defined in file libavutil.so.50
with link time reference"

Not sure why it does not look in /usr/lib/ but I guess that's the problem.

Maybe I should just unintall FFmpeg HEAD now and rebuild Audacity HEAD with v10
to satisfy myself Audacity HEAD patched is OK with the native AC encoder?
However shouldn't Audacity sense a problem when I export M4A with Ubuntu FFmpeg
instead of treating you to its (very long) M4A export progress dialogue?

(In reply to comment #74)
> My only issue was with the stereo m4a I exported using Ubuntu's FFmpeg so using
> the native aac encoder. This is the log when importing it into Audacity with
> either version of Audacity:
> Error: Stream 0 start_time = 0, that would be 0.000000 milliseconds.
>
I think this test in Audacity needs to be changed just a bit. It looks like
LRN wasn't quite sure what was supposed to happen when start_time was defined.
In this case, start_time is set to 0 instead of the "undefined" value. I think
it should probably be changed to check for a non-zero start time in addition to
the existing check.

> If I use Ubuntu's FFmpeg at the Audacity CLI with AUdacity HEAD or 1.3.12 I get
> no export at all and
>
> "/usr/bin/ffmpeg: relocation error: /usr/local/lib/libswscale.so.0: symbol
> av_opt_set_defaults, version LIBAVUTIL_50 not defined in file libavutil.so.50
> with link time reference"
>
This is just that FFmpeg HEAD's libs were being found before the Ubuntu's, but
the Ubuntu ffmpeg command was be found before the FFmpeg HEAD's ffmpeg command.
 You could check your PATH and LD_LIBRARY_PATH environment variables to make
sure /usr/local/* comes before the /usr/* fellas.

Or just uninstall the FFmpeg HEAD stuff as you suggested.

Leland

Created an attachment (id=147)
Don't just bypass the metadata dialog, bypass writing the tags too!!!

This skips writing the tags if they aren't supported by the format. It was
only a one line change, so "major" testing shouldn't be required.

Is the new FFmpeg support in these patches backwards-compatible beyond 0.5? So
if someone on Win went from 1.3.6 Beta to 1.3.13 Beta, they would not need to
update their FFmpeg? I don't think it matters if not, just asking.

(In reply to comment #77)
> Is the new FFmpeg support in these patches backwards-compatible beyond 0.5? So
> if someone on Win went from 1.3.6 Beta to 1.3.13 Beta, they would not need to
> update their FFmpeg? I don't think it matters if not, just asking.

Probably not. I only tested as far back as the current FFmpeg for Windows
libraries that are on Buanzo's site.

Leland

Applied v11 on Windows and Ubuntu (uninstalled FFmoeg HEAD so back to Ubuntu
FFmpeg).

Only minor WMA problem left is visibility of exported metadata to other apps -
see http://bugzilla.audacityteam.org/show_bug.cgi?id=134#c5 .

32-bit WAV files come in OK via FFmpeg as 32-bit on Win and Ubuntu (even with
FFmpeg 0.5).

AAC export on Ubuntu (native encoder using "M4A files") is still wrong - seems
to be a silent file - "playable" but very small file size. Are we still
expecting that?

AAC files (even ones that are correct) and WNA files on both Win and Ubuntu
show that "Error" about start time that "would be so many milliseconds". AC3
and AMR NB do not show this "error"

(In reply to comment #79)
> AAC export on Ubuntu (native encoder using "M4A files") is still wrong - seems
> to be a silent file - "playable" but very small file size. Are we still
> expecting that?

I'm pretty sure the small file size is expected, but the silent file is not.
Can you send me one of those via email?

> AAC files (even ones that are correct) and WNA files on both Win and Ubuntu
> show that "Error" about start time that "would be so many milliseconds". AC3
> and AMR NB do not show this "error"

The more I think about it, the more I believe we should add a check for a 0
start time and just ignore it. A 0 start time and no start time at all are
just the same thing after all.

I won't do a v12 patch, but once it is committed, don't let me forget to fix
the start time check. :-)

(In reply to comment #80)
>> AAC export on Ubuntu (native encoder using "M4A files") is still wrong -
>> seems to be a silent file - "playable" but very small file size.
> I'm pretty sure the small file size is expected, but the silent file is not.
> Can you send me one of those via email?
I have sent you "silent.m4a". But I cannot reproduce an issue now, either with
WAV or WMA input or tone input. That file was produced last night though there
is a very small possibility it came from the 1.3.12 Ubuntu release and not from
1.3.13 - I did not name it clearly enough and it was the only M4A I had time to
export. However the 1.3.12 Ubuntu release is not currently producing silent
files either, so I'm still kind of suspicious.

What I want to do now to complete testing is to generate AMR/AC3/M4A/WMA files
outside Audacity and try those on Audacity on Win and Ubuntu. If those files
actually import and play properly I think we could close this once it is
committed. Then:

* Have a P4 moonphase bug for silenced M4A exports with native encoder.

* Bug 317 stands but modified to be an issue with either AAC encoder when you
export using "M4A files". Think it should be P3 as it is very annoying.

* I've already opened Bug 339 "watch libfaad and native AAC encoder in case
they fix issues that prevent us using them in Audacity's FFmpeg". That gives us
a release note:

"(Linux) Mono AAC files import as stereo if FFmpeg uses the libfaad decoder.
Files exported using the FFmpeg native encoder are of very poor quality. These
are both issues with the library itself."

So this means we do what you suggested and in the Win/Mac FFmpeg we distribute,
we use the native AAC decoder and the libfaac encoder.

Does this cover everything?

> don't let me forget to fix the start time check.
Now at bug 338.(In reply to comment #80)

(In reply to comment #81)
>
> Does this cover everything?
>
I believe so. Let's get the v11 patch committed to get it into the hands of
more users and more environments to see if there's more issues.

> What I want to do now to complete testing is to generate AMR/AC3/M4A/WMA files
> outside Audacity and try those on Audacity on Win and Ubuntu.
This did not provide any problems in terms of correct audio being imported.

All the residual issues from this AFAICT are now at bug 317, bug 338, bug 339,
bug 340, bug 341, bug 342.

So whoever commits the bug can resolve it fixed because it has had its QA
testing already. Thanks, Leland.

(In reply to comment #83)
> So whoever commits the bug can resolve it fixed because it has had its QA
> testing already. Thanks, Leland.

Is this supposed to wait until after 1.3.13 is released? Or should it get
committed now?

(In reply to comment #84)
> Is this supposed to wait until after 1.3.13 is released? Or should it get
> committed now?
I would agree to committing it because I think it would reduce the number of
Linux complaints about FFmpeg, and it's been pretty well tested on my systems.
But you need someone else to agree too.

I don't know if my vote counts, but I would like to see this patch committed.
If the patch is not included in the upcoming release, I will apply the patch in
the Debian/Ubuntu package.

Created an attachment (id=153)
Change m4a export options to bitrate

This changes the m4a export options to a more common bitrate instead of
quality.

Tried v12 on win 7 x64 so far. Main finding so far is that exported bit rates
are not correct. Exporting a stereo music track, both with FFmpeg 0.5 and 0.6
and according to Medianfo and iTunes,

24 kbps exports as 60 kbps

96 and 256 kbps both export as 150 kbps (the exported files are the same size).

Scanned the patch. Nice work with the function declaration macros, made it a
lot more readable. And your changes are well documented.

Why change several wxLogDebug() calls to wxLogMessage()? I would think that
type of info would only be clutter to most users, and relevant only to those of
us building Debug versions.

I see these changes are not backward compatible, but if Gale's okay with that
for users, I say commit this patch.

(In reply to comment #88)
> Tried v12 on win 7 x64 so far. Main finding so far is that exported bit rates
> are not correct. Exporting a stereo music track, both with FFmpeg 0.5 and 0.6
> and according to Medianfo and iTunes,
>
> 24 kbps exports as 60 kbps
>
> 96 and 256 kbps both export as 150 kbps (the exported files are the same size).

Yep, I noticed that too. But, the ffmpeg command does the same thing:

From WAV to M4A at 256kbps...

llama:~$ /usr/local/lib/audacity/ffmpeg -i 1.wav -ab 256k 2.m4a

<snip>

[wav @ 0x1009810]max_analyze_duration reached
[wav @ 0x1009810]Estimating duration from bitrate, this may be inaccurate
Input #0, wav, from '1.wav':
  Duration: 00:00:30.00, bitrate: 705 kb/s
    Stream #0.0: Audio: pcm_s16le, 44100 Hz, 1 channels, s16, 705 kb/s
Output #0, ipod, to '2.m4a':
  Metadata:
    encoder : Lavf52.64.2
    Stream #0.0: Audio: libfaac, 44100 Hz, 1 channels, s16, 256 kb/s
Stream mapping:
  Stream #0.0 -> #0.0
Press [q] to stop encoding
size= 238kB time=29.93 bitrate= 65.2kbits/s
video:0kB audio:228kB global headers:0kB muxing overhead 4.718516%

And from that M4A back to WAV...

llama:~$ /usr/local/lib/audacity/ffmpeg -i 2.m4a -ab 256k 2.wav

<snip>

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '2.m4a':
  Metadata:
    major_brand : M4A
    minor_version : 512
    compatible_brands: isomiso2
    encoder : Lavf52.64.2
  Duration: 00:00:29.93, start: 0.000000, bitrate: 65 kb/s
    Stream #0.0(und): Audio: libfaad, 44100 Hz, 2 channels, s16, 62 kb/s
Output #0, wav, to '2.wav':
  Metadata:
    encoder : Lavf52.64.2
    Stream #0.0(und): Audio: pcm_s16le, 44100 Hz, 2 channels, s16, 1411 kb/s
Stream mapping:
  Stream #0.0 -> #0.0
Press [q] to stop encoding
size= 5152kB time=29.91 bitrate=1411.2kbits/s
video:0kB audio:5152kB global headers:0kB muxing overhead 0.000834%

Notice how even though I specified 256kbps when I converted to M4A, it actually
wound up being 62kbps.

(In reply to comment #89)
> Scanned the patch. Nice work with the function declaration macros, made it a
> lot more readable. And your changes are well documented.
>
> Why change several wxLogDebug() calls to wxLogMessage()? I would think that
> type of info would only be clutter to most users, and relevant only to those of
> us building Debug versions.
>
Did that because it was "hiding" what was going on when searching for the
libraries. I felt they would assist with debugging problems when users
complained about Audacity not finding the FFmpeg libraries. And since the
users get Release versions, the messages wouldn't be available.

Maybe I'm misunderstanding the reason for the log. What information in there
does the user any good? Isn't it more for the folks that are assisting users
with problems?

> I see these changes are not backward compatible, but if Gale's okay with that
> for users, I say commit this patch.

How far back do you want it to go? You can't even download any version from
the ffmpeg site before 0.5.1 and while I haven't specifically tested with that
version, why would I need to test with anything older than the version you guys
have been supplying on Buanzo's site since FFmpeg support went public?

The only point about backwards-compatibility as I see it is to save people
coming from 1.3.6 and 1.3.7 (which had our earliest version of FFmpeg) having
to get the latest FFmpeg when they upgrade Audacity. Even without this patch
those 1.3.6/1.3.7 users would have to upgrade to the current FFmpeg available
at Buanzo's site, so we are not making things any worse for them. And if this
patch was in 1.3.13 or 1.3.14, users upgrading from 1.3.8+ would be able to
carry on with their older FFmpeg 0.5 without having to update to our FFmpeg 0.6
when we release it, so it's better for them. But to answer the question, no the
1.3.6/1.3.7 FFmpeg (the October 2008 versions here):
http://lrn.mooo.com/other/gsoc/ffmpegcity/ffmpeg/distributable/

are rejected by 1.3.13 with this patch applied.

Yes the log messages are mainly for support workers. I'm +1 on leaving them in
until we are sure we have cracked all the issues with "other" versions of
FFmpeg on the system preventing "our" FFmpeg getting picked up. We can revert
the messages to "debug" then if we want.

Leland, do you think the reason LRN went for quality was because FFmpeg has a
problem if you simplistically specify the bit rate? Although users don't
like/understand those quality settings, they seem to be functional - higher
quality = higher bit rate. Can you see any magic to get around this? If not,
then quality settings (but also indicating the likely bit rate resulting) might
be a reasonable compromise (probably using a combo box, not a slider). And we
could leave that for now in the interests of applying this patch if Vaughan is
agreeable to it.

(In reply to comment #92)
> Leland, do you think the reason LRN went for quality was because FFmpeg has a
> problem if you simplistically specify the bit rate? Although users don't
> like/understand those quality settings, they seem to be functional - higher
> quality = higher bit rate. Can you see any magic to get around this? If not,
> then quality settings (but also indicating the likely bit rate resulting) might
> be a reasonable compromise (probably using a combo box, not a slider). And we
> could leave that for now in the interests of applying this patch if Vaughan is
> agreeable to it.

I totally agree that the Quality method should be used. But, I think LRN had
it right when he used a slider. We wouldn't be able to provide an accurate
value if we tried to assign a bitrate to a specific quality value.

(In reply to comment #93)
> I totally agree that the Quality method should be used. But, I think LRN had
> it right when he used a slider. We wouldn't be able to provide an accurate
> value if we tried to assign a bitrate to a specific quality value.
Of the three apps I know about, SUPER (using FFmpeg) and iTunes both use kbps
in a dropdown. Nero (as implemented in dBPowerAmnp which is a fringe app) uses
a slider, but indicates the approximate bit rate on the slider. I have not
tested if SUPER files produce the stated values in the dropdown.

The issue though as I see it is that users do the conversion to AAC in iTunes
or elsewhere because they can't figure out what our Quality slider will give
them. Also they don't want to bother with the large number of possible quality
choices that our slider presents.

The bit rate is only an indication anyway (I do think iTunes isn't clear enough
about that). Is it possible to take a dozen or less quality settings, but have
a dropdown for those indicating the quality then the bit rate range (exactly as
we do for MP3 VBR)? My concern with the slider is that it would have to be a
lot wider (and maybe a lot of work) to carry target bit rate information.

(In reply to comment #91)

from Leland Lucius <email address hidden> 2011-04-01 00:48:46 EDT ---
>> <snip>
>> Why change several wxLogDebug() calls to wxLogMessage()? I would think that
>> type of info would only be clutter to most users, and relevant only to those of
>> us building Debug versions.
>>
> Did that because it was "hiding" what was going on when searching for the
> libraries. I felt they would assist with debugging problems when users
> complained about Audacity not finding the FFmpeg libraries. And since the
> users get Release versions, the messages wouldn't be available.

Yes, obviously I know that. Wanted to raise the issue because they formerly
were wxLogMessage() and a few months ago I changed them to wxLogDebug() because
I thought it was just cruft, and FFmpeg had been unchanged for a while. Nobody
complained, so I thought that was justified.

I think the only reason to show them in release versions is if we are actually
still getting FFmpeg errors -- but as we're using a new FFmpeg, I think yes,
leave them in at least for this release.

>
> Maybe I'm misunderstanding the reason for the log. What information in there
> does the user any good? Isn't it more for the folks that are assisting users
> with problems?

It's useful for debugging, too. :-)

And some wxLogDebug() calls are good to leave in, although probably many should
be commented out when the debugging is completed.

>
>> I see these changes are not backward compatible, but if Gale's okay with that
>> for users, I say commit this patch.
>
> How far back do you want it to go?

I wasn't advocating for *any* backward compatibility, personally. Just wanted
to double check with Gale because I said commit the patch, but that question
had not been resolved.

(In reply to comment #92)

from Gale Andrews <email address hidden> 2011-04-01 14:17:13 BST ---
> The only point about backwards-compatibility as I see it is to save people
> coming from 1.3.6 and 1.3.7 (which had our earliest version of FFmpeg) having
> to get the latest FFmpeg when they upgrade Audacity. Even without this patch
> those 1.3.6/1.3.7 users would have to upgrade to the current FFmpeg available
> at Buanzo's site, so we are not making things any worse for them. And if this
> patch was in 1.3.13 or 1.3.14, users upgrading from 1.3.8+ would be able to
> carry on with their older FFmpeg 0.5 without having to update to our FFmpeg 0.6
> when we release it, so it's better for them. But to answer the question, no the
> 1.3.6/1.3.7 FFmpeg (the October 2008 versions here):
> http://lrn.mooo.com/other/gsoc/ffmpegcity/ffmpeg/distributable/

I think those are not too much to ask of beta users, so I am -1 on backward
compatibility.

Okay. So I'm going to go ahead and commit the version 11. Gale and I will
work out what the M4A options should be as a separate patch since that will
take some discussion and testing.

(In reply to comment #97)
> I'm going to go ahead and commit the version 11
Agreed. M4A quality slider issue is now at bug 344.

Leland committed as r11055 so Status changed to DEVEL - FIX MADE, though I have
tested as much as I can. Would Bill like to test this on Mac?

(From update of attachment 147)
this version was committed.

Are we providing FFmpeg 0.6 binaries for Win/Mac for 1.3.13 Beta?

(In reply to comment #101)
> Are we providing FFmpeg 0.6 binaries for Win/Mac for 1.3.13 Beta?

This might be something that the devel subscribers would like to discuss.
Personally, I say go for it...

(In reply to comment #102)
> This might be something that the devel subscribers would like to discuss.
> Personally, I say go for it...
It's expected FFmpeg 0.6.2 will be released for Win/Mac users when 1.3.13 is
released. A cursory test of 0.6.2 on Win XP suggests 0.6.2 is OK.

This is RESOLVED-FIXED as it is committed and will be in 1.3.13. This also
resolves bug 274 (P2).