Discussion:
[Libav-user] Requesting help to port Audacity to recent FFmpeg
(too old to reply)
Michael Niedermayer
2014-05-14 17:27:38 UTC
Permalink
Hi
Hi,
Audacity, the digital audio editor used by millions, has import/export
support for a wide range of audio formats using the FFmpeg libraries.
Audacity compiles only against FFmpeg < 1.0 [1]. The FFmpeg libraries
have changed from time to time and Audacity needs non-trivial work to
support any supported FFmpeg version. Sadly, no Audacity developer has
the time and skill to port Audacity to a recent FFmpeg API.
That's why I send this mail to this mailing list to request help. Is
there anyone who has the time and skill to help porting Audacity to the
latest FFmpeg API version?
[1] http://bugzilla.audacityteam.org/show_bug.cgi?id=606
ive updated audacity to build with ffmpeg HEAD
note, this works but is not finished, so please clone/fork it and help

https://github.com/michaelni/audacity

also it still uses some internal API parts from ffmpeg
so it needs this patch to ffmpeg:

diff --git a/libavformat/libavformat.v b/libavformat/libavformat.v
index 0b47668..0d5d3b0 100644
--- a/libavformat/libavformat.v
+++ b/libavformat/libavformat.v
@@ -21,6 +21,8 @@ LIBAVFORMAT_$MAJOR {
ffurl_size;
ffurl_write;
ffurl_protocol_next;
+ ffio_fdopen;
+ ffurl_register_protocol;
url_open;
url_close;
url_write;

and it needs to #include libavformat/url.h (which isnt installed be
default)

Planar audio input works, but can certainly be implemented more optimal
and faster in audacity, export works but not planar export.
ive commented some options out as they are handled differently now
and audacity certainly wants a proper GUI that lists for each codec
what options/parameters it supports and not just the old 5 ones hacked
back in. I dunno audacity well enough to quickly add such GUI and
didnt want to waste time to hack these 5 back in as they where

The useage of URLProtocol also should be removed, i assume this can
be simplified quite a bit

again, if you are reading this and care about audacity or ffmpeg,
please clone/fork my repo above and pick some issue up and improve
the code. if noone does ill probably continue to work on this as i
find time

Iam also CCing audacity-devel as they probably want to know about this

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct answer.
Claudio Freire
2014-05-14 19:41:54 UTC
Permalink
Post by Michael Niedermayer
diff --git a/libavformat/libavformat.v b/libavformat/libavformat.v
index 0b47668..0d5d3b0 100644
--- a/libavformat/libavformat.v
+++ b/libavformat/libavformat.v
@@ -21,6 +21,8 @@ LIBAVFORMAT_$MAJOR {
ffurl_size;
ffurl_write;
ffurl_protocol_next;
+ ffio_fdopen;
+ ffurl_register_protocol;
url_open;
url_close;
url_write;
and it needs to #include libavformat/url.h (which isnt installed be
default)
If you need subscribers to the idea of re-publicizing the register
protocol APIs, count me in. I also use it in one of the projects that
needs an ffmpeg update, and that's probably one of the biggest tasks
blocking me. Since ffmpeg there is an optional requirement, I keep
postponing the port.

Having that API back into ffmpeg would certainly most certainly help.
Michael Niedermayer
2014-05-18 00:30:00 UTC
Permalink
Post by Claudio Freire
Post by Michael Niedermayer
diff --git a/libavformat/libavformat.v b/libavformat/libavformat.v
index 0b47668..0d5d3b0 100644
--- a/libavformat/libavformat.v
+++ b/libavformat/libavformat.v
@@ -21,6 +21,8 @@ LIBAVFORMAT_$MAJOR {
ffurl_size;
ffurl_write;
ffurl_protocol_next;
+ ffio_fdopen;
+ ffurl_register_protocol;
url_open;
url_close;
url_write;
and it needs to #include libavformat/url.h (which isnt installed be
default)
If you need subscribers to the idea of re-publicizing the register
protocol APIs, count me in. I also use it in one of the projects that
needs an ffmpeg update, and that's probably one of the biggest tasks
blocking me. Since ffmpeg there is an optional requirement, I keep
postponing the port.
Having that API back into ffmpeg would certainly most certainly help.
for audacity urlprotocol is unneeded, ive just changed the code not
to use it and it works fine (see github), its simpler as well.

src/FFmpeg.cpp | 131 ++++++++++++++-----------------------------
src/FFmpeg.h | 48 ++++------------
src/export/ExportFFmpeg.cpp | 2 +-
3 files changed, 55 insertions(+), 126 deletions(-)

But yes, there are cases (like image2) that need urlprotocol, if
someone wants urlprotocol back a patch is welcome, the ABI situation
with it should be explained in the urlprotocol documentation though so
people dont get bitten by it.

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

DNS cache poisoning attacks, popular search engine, Google internet authority
dont be evil, please
Michael Niedermayer
2014-05-20 17:17:07 UTC
Permalink
Hi
On Wed, 14 May 2014 19:27:38 +0200
That's why I send this mail to this mailing list to request help. Is
there anyone who has the time and skill to help porting Audacity to
the latest FFmpeg API version?
[1] http://bugzilla.audacityteam.org/show_bug.cgi?id=606
I think I'm right in saying that no-one on the audacity-devel list was
specifically aware of this work/request (or I might have said something
earlier).
As a result of this problem, one of the Audacity contributors, Leyland
Lucius, has been perusing the use of Gstreamer as an abstraction layer
for ffmpeg. This work has recently arrived in Audacity SVN, so you
should be able to see where it is at (it isn't working for me, but I
don't think it's Leyland's fault).
I wasnt aware of that, but still is there no interrest in directly
supporting FFmpeg ?
Also i just fixed planar export & put the disabled options back so
my github should contain a audacity that fully works with latest
ffmpeg, of course there will be bugs but iam happy to fix them if
they get reported to me ...
The rationale for doing this is that the Gstreamer 1.0 API is much more
stable than the libAV one, and there is an (actively maintained)
gst-plugin-libav which provides the functionality of libAV through that
API. Thus the problem of providing up-to-date builds of libAV is
reduced, and an abstraction layer is provided.
Iam quite aware of the API stability issues in our API.
Its a result of FFmpeg supporting all features and bugfixes as well
as to be API compatible to the fork (libav) and that changing the API
all the time.

One question here would be if there would be interrest if FFmpeg would
provide a seperate simple API which isnt designed to be as efficient
as possible and which makes no attempt to be compatible with libav.
such API could then be long term stable
?
This idea did come up already a few times IIRC. Just noone imlpemented
it yet, but the more people support the idea the more likely someone
will sit down and write it ...
This also has the benefit of allowing (in principal) any other codecs
which are supported in Gstreamer (or by plugins for it) to be added to
Audacity relatively easily. This is something we hope to make modular,
so that it doesn't need a complete new build of audacity to use new
gstreamer plug-ins, and every download of Audacity doesn't have to ship
with every possible codec library.
hmm, i dont know exactly which codecs gstreamer supports but ffmpeg
also supports quite a few external libs as codecs, the ones ive enabled
on my local build:

decoders:
A....D libfdk_aac Fraunhofer FDK AAC (codec aac)
A....D libopencore_amrnb OpenCORE AMR-NB (Adaptive Multi-Rate Narrow-Band) (codec amr_nb)
A....D libopencore_amrwb OpenCORE AMR-WB (Adaptive Multi-Rate Wide-Band) (codec amr_wb)
A....D libgsm libgsm GSM (codec gsm)
A....D libgsm_ms libgsm GSM Microsoft variant (codec gsm_ms)
A....D libilbc iLBC (Internet Low Bitrate Codec) (codec ilbc)
A....D libopus libopus Opus (codec opus)
A....D libspeex libspeex Speex (codec speex)
A..... libvorbis libvorbis (codec vorbis)

encoders:
A..... libfaac libfaac AAC (Advanced Audio Coding) (codec aac)
A..... libfdk_aac Fraunhofer FDK AAC (codec aac)
A..... libvo_aacenc Android VisualOn AAC (Advanced Audio Coding) (codec aac)
A..... libaacplus libaacplus AAC+ (Advanced Audio Codec with SBR+PS) (codec aac)
A..... libopencore_amrnb OpenCORE AMR-NB (Adaptive Multi-Rate Narrow-Band) (codec amr_nb)
A..... libvo_amrwbenc Android VisualOn AMR-WB (Adaptive Multi-Rate Wide-Band) (codec amr_wb)
A..... libgsm libgsm GSM (codec gsm)
A..... libgsm_ms libgsm GSM Microsoft variant (codec gsm_ms)
A..... libilbc iLBC (Internet Low Bitrate Codec) (codec ilbc)
A..... libmp3lame libmp3lame MP3 (MPEG audio layer 3) (codec mp3)
A..... libopus libopus Opus (codec opus)
A..... libspeex libspeex Speex (codec speex)
A..... libvorbis libvorbis (codec vorbis)

changing these would generally require a rebuild of libavcodec though
but not audacity.
Also if someone wants to change ffmpegs external lib support to use
dlopen for some or all cases, i surely wouldnt mind ...

Also according to:
./ffmpeg -filters | egrep '\->A|A\-' | wc
there are 58 audio filters in ffmpegs libavfilter (not counting ones
that arent enabled in my local build)
So maybe libavfilter support might be interresting to audacity too ?

And the codecs in ffmpeg support quite a few more options than what
is available to be set from audacity currently. It should be fairly
easy to add generic option support for someone who knows the
audacity API.
random example:
./ffmpeg -help encoder=libopus
...
Encoder libopus [libopus Opus]:
Threading capabilities: no
Supported sample rates: 48000 24000 16000 12000 8000
Supported sample formats: s16 flt
Supported channel layouts: mono stereo 3.0 quad 5.0 5.1 6.1 7.1
libopus AVOptions:
-application <int> E...A... Intended application type (from 2048 to 2051) (default 2049)
voip E...A... Favor improved speech intelligibility
audio E...A... Favor faithfulness to the input
lowdelay E...A... Restrict to only the lowest delay modes
-frame_duration <float> E...A... Duration of a frame in milliseconds (from 2.5 to 60) (default 20)
-packet_loss <int> E...A... Expected packet loss percentage (from 0 to 100) (default 0)
-vbr <int> E...A... Variable bit rate mode (from 0 to 2) (default 1)
off E...A... Use constant bit rate
on E...A... Use variable bit rate
constrained E...A... Use constrained VBR


Thanks
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"
Gale (Audacity Team)
2014-05-20 20:24:58 UTC
Permalink
Post by Michael Niedermayer
One question here would be if there would be interrest if FFmpeg would
provide a seperate simple API which isnt designed to be as efficient
as possible and which makes no attempt to be compatible with libav.
such API could then be long term stable?
This idea did come up already a few times IIRC. Just noone imlpemented
it yet, but the more people support the idea the more likely someone
will sit down and write it ...
How popular would that be with users, or with Linux distributions (it would
be a third alternative to standard FFmpeg and standard libav)?

Because FFmpeg/libav is so "bleeding edge" it seems that users often want
to use the latest possible version of it (even on Windows). While you can
use the latest FFmpeg binary for export from Audacity using "(external
program)" it seems this won't work consistently for importing unless the
same FFmpeg version is used, hence another reason to try GStreamer.

Incidentally GStreamer support in Audacity doesn't work yet on Windows
for me, but I know Leland is on to it.



Gale






--
View this message in context: http://audacity.238276.n2.nabble.com/Re-Libav-user-Requesting-help-to-port-Audacity-to-recent-FFmpeg-tp7561837p7561900.html
Sent from the audacity-devel mailing list archive at Nabble.com.
Benjamin Drung
2014-05-20 21:41:53 UTC
Permalink
Hi Michael,

first, let me thank you for your work.
Post by Michael Niedermayer
Hi
On Wed, 14 May 2014 19:27:38 +0200
That's why I send this mail to this mailing list to request help. Is
there anyone who has the time and skill to help porting Audacity to
the latest FFmpeg API version?
[1] http://bugzilla.audacityteam.org/show_bug.cgi?id=606
I think I'm right in saying that no-one on the audacity-devel list was
specifically aware of this work/request (or I might have said something
earlier).
I had the spontaneous idea to ask for help on the libav-user mailing
list. I didn't communicated this idea to any audacity developer or
mailing list.
Post by Michael Niedermayer
As a result of this problem, one of the Audacity contributors, Leyland
Lucius, has been perusing the use of Gstreamer as an abstraction layer
for ffmpeg. This work has recently arrived in Audacity SVN, so you
should be able to see where it is at (it isn't working for me, but I
don't think it's Leyland's fault).
I wasnt aware of that, but still is there no interrest in directly
supporting FFmpeg ?
The lacking interest in continue supporting FFmpeg was caused by the
missing manpower to keep Audacity updated against the changing API of
FFmpeg.

I assume that no Audacity will be against having FFmpeg support in the
source code if this support is kept up-to-date. I like to commit your
work to the Audacity SVN so that we have both - support for FFmpeg and
Gstreamer.
Post by Michael Niedermayer
Also i just fixed planar export & put the disabled options back so
my github should contain a audacity that fully works with latest
ffmpeg, of course there will be bugs but iam happy to fix them if
they get reported to me ...
I tested your patches with FFmpeg 2.2.1-2 on Ubuntu 14.04 with the
--disable-dynamic-loading configure flag. To succeed compiling, I had to
apply the attached 0001*.patch.

Then I modified the code and successfully compiled Audacity against the
libav version from Ubuntu 14.04. For that I had to create the second
0002*.patch (there you have to use --disable-dynamic-loading)

Importing and exporting ac3 and wma works with both libraries (including
setting the audio quality).

I found some issues:

1) There was a debugging line left in the code: fprintf(stderr, "READ %d
ret %d\n", size, ret);

2) I can't export audio as mp4. Neither as mp4 export, nor as custom
FFmpeg export (can't be selected there). FFmpeg has mp4 support enabled:

$ ffmpeg -formats 2>/dev/null | grep mp4
D mov,mp4,m4a,3gp,3g2,mj2 QuickTime / MOV
E mp4 MP4 (MPEG-4 Part 14)
Post by Michael Niedermayer
The rationale for doing this is that the Gstreamer 1.0 API is much more
stable than the libAV one, and there is an (actively maintained)
gst-plugin-libav which provides the functionality of libAV through that
API. Thus the problem of providing up-to-date builds of libAV is
reduced, and an abstraction layer is provided.
Iam quite aware of the API stability issues in our API.
Its a result of FFmpeg supporting all features and bugfixes as well
as to be API compatible to the fork (libav) and that changing the API
all the time.
One question here would be if there would be interrest if FFmpeg would
provide a seperate simple API which isnt designed to be as efficient
as possible and which makes no attempt to be compatible with libav.
such API could then be long term stable
?
This idea did come up already a few times IIRC. Just noone imlpemented
it yet, but the more people support the idea the more likely someone
will sit down and write it ...
IMO it would make sense to have a subset of the API (it doesn't have to
be a separate API) where you promise long term stability.
Post by Michael Niedermayer
This also has the benefit of allowing (in principal) any other codecs
which are supported in Gstreamer (or by plugins for it) to be added to
Audacity relatively easily. This is something we hope to make modular,
so that it doesn't need a complete new build of audacity to use new
gstreamer plug-ins, and every download of Audacity doesn't have to ship
with every possible codec library.
Are there really codecs that are supported by Gstreamer, but not by
FFmpeg?
Post by Michael Niedermayer
hmm, i dont know exactly which codecs gstreamer supports but ffmpeg
also supports quite a few external libs as codecs, the ones ive enabled
A....D libfdk_aac Fraunhofer FDK AAC (codec aac)
A....D libopencore_amrnb OpenCORE AMR-NB (Adaptive Multi-Rate Narrow-Band) (codec amr_nb)
A....D libopencore_amrwb OpenCORE AMR-WB (Adaptive Multi-Rate Wide-Band) (codec amr_wb)
A....D libgsm libgsm GSM (codec gsm)
A....D libgsm_ms libgsm GSM Microsoft variant (codec gsm_ms)
A....D libilbc iLBC (Internet Low Bitrate Codec) (codec ilbc)
A....D libopus libopus Opus (codec opus)
A....D libspeex libspeex Speex (codec speex)
A..... libvorbis libvorbis (codec vorbis)
A..... libfaac libfaac AAC (Advanced Audio Coding) (codec aac)
A..... libfdk_aac Fraunhofer FDK AAC (codec aac)
A..... libvo_aacenc Android VisualOn AAC (Advanced Audio Coding) (codec aac)
A..... libaacplus libaacplus AAC+ (Advanced Audio Codec with SBR+PS) (codec aac)
A..... libopencore_amrnb OpenCORE AMR-NB (Adaptive Multi-Rate Narrow-Band) (codec amr_nb)
A..... libvo_amrwbenc Android VisualOn AMR-WB (Adaptive Multi-Rate Wide-Band) (codec amr_wb)
A..... libgsm libgsm GSM (codec gsm)
A..... libgsm_ms libgsm GSM Microsoft variant (codec gsm_ms)
A..... libilbc iLBC (Internet Low Bitrate Codec) (codec ilbc)
A..... libmp3lame libmp3lame MP3 (MPEG audio layer 3) (codec mp3)
A..... libopus libopus Opus (codec opus)
A..... libspeex libspeex Speex (codec speex)
A..... libvorbis libvorbis (codec vorbis)
changing these would generally require a rebuild of libavcodec though
but not audacity.
Also if someone wants to change ffmpegs external lib support to use
dlopen for some or all cases, i surely wouldnt mind ...
./ffmpeg -filters | egrep '\->A|A\-' | wc
there are 58 audio filters in ffmpegs libavfilter (not counting ones
that arent enabled in my local build)
So maybe libavfilter support might be interresting to audacity too ?
And the codecs in ffmpeg support quite a few more options than what
is available to be set from audacity currently. It should be fairly
easy to add generic option support for someone who knows the
audacity API.
./ffmpeg -help encoder=libopus
...
Threading capabilities: no
Supported sample rates: 48000 24000 16000 12000 8000
Supported sample formats: s16 flt
Supported channel layouts: mono stereo 3.0 quad 5.0 5.1 6.1 7.1
-application <int> E...A... Intended application type (from 2048 to 2051) (default 2049)
voip E...A... Favor improved speech intelligibility
audio E...A... Favor faithfulness to the input
lowdelay E...A... Restrict to only the lowest delay modes
-frame_duration <float> E...A... Duration of a frame in milliseconds (from 2.5 to 60) (default 20)
-packet_loss <int> E...A... Expected packet loss percentage (from 0 to 100) (default 0)
-vbr <int> E...A... Variable bit rate mode (from 0 to 2) (default 1)
off E...A... Use constant bit rate
on E...A... Use variable bit rate
constrained E...A... Use constrained VBR
Thanks
--
Benjamin Drung
Debian & Ubuntu Developer
Michael Niedermayer
2014-05-21 00:16:47 UTC
Permalink
Hi

On Tue, May 20, 2014 at 11:41:53PM +0200, Benjamin Drung wrote:
[...]
Post by Benjamin Drung
Post by Michael Niedermayer
As a result of this problem, one of the Audacity contributors, Leyland
Lucius, has been perusing the use of Gstreamer as an abstraction layer
for ffmpeg. This work has recently arrived in Audacity SVN, so you
should be able to see where it is at (it isn't working for me, but I
don't think it's Leyland's fault).
I wasnt aware of that, but still is there no interrest in directly
supporting FFmpeg ?
The lacking interest in continue supporting FFmpeg was caused by the
missing manpower to keep Audacity updated against the changing API of
FFmpeg.
I assume that no Audacity will be against having FFmpeg support in the
source code if this support is kept up-to-date.
I like to commit your
work to the Audacity SVN so that we have both - support for FFmpeg and
Gstreamer.
that sounds great
Post by Benjamin Drung
Post by Michael Niedermayer
Also i just fixed planar export & put the disabled options back so
my github should contain a audacity that fully works with latest
ffmpeg, of course there will be bugs but iam happy to fix them if
they get reported to me ...
I tested your patches with FFmpeg 2.2.1-2 on Ubuntu 14.04 with the
--disable-dynamic-loading configure flag. To succeed compiling, I had to
apply the attached 0001*.patch.
applied that one to my tree, should i apply other fixes from you there
too or wait until they reach upstream svn ?


[...]
Post by Benjamin Drung
1) There was a debugging line left in the code: fprintf(stderr, "READ %d
ret %d\n", size, ret);
fixed
Post by Benjamin Drung
2) I can't export audio as mp4. Neither as mp4 export, nor as custom
$ ffmpeg -formats 2>/dev/null | grep mp4
D mov,mp4,m4a,3gp,3g2,mj2 QuickTime / MOV
E mp4 MP4 (MPEG-4 Part 14)
hmmm, what do you mean by "mp4" ?
there are alot of audio codecs that can be stored in mp4, for example
aac, mp3, vorbis, also there are multiple ways to encode aac, libfaac
ffmpegs native encoder and a few others ...

I tried a few things and found a few bugs (which i fixed) but iam
not convinced i fixed the issue you describe
Post by Benjamin Drung
Post by Michael Niedermayer
The rationale for doing this is that the Gstreamer 1.0 API is much more
stable than the libAV one, and there is an (actively maintained)
gst-plugin-libav which provides the functionality of libAV through that
API. Thus the problem of providing up-to-date builds of libAV is
reduced, and an abstraction layer is provided.
Iam quite aware of the API stability issues in our API.
Its a result of FFmpeg supporting all features and bugfixes as well
as to be API compatible to the fork (libav) and that changing the API
all the time.
One question here would be if there would be interrest if FFmpeg would
provide a seperate simple API which isnt designed to be as efficient
as possible and which makes no attempt to be compatible with libav.
such API could then be long term stable
?
This idea did come up already a few times IIRC. Just noone imlpemented
it yet, but the more people support the idea the more likely someone
will sit down and write it ...
IMO it would make sense to have a subset of the API (it doesn't have to
be a separate API) where you promise long term stability.
thats tricky
for example all the current API works based on AVPackets
and for example libav plans to remove the destruct callback from
AVPackets
so any subset would break
sure we could just keep the destruct callback and ignore libav removing
it but AVPackets are part of the public API & ABI and if we do that
then ffmpeg would not be ABI compatible with libav anymore which we
mostly are currently.
Post by Benjamin Drung
Post by Michael Niedermayer
This also has the benefit of allowing (in principal) any other codecs
which are supported in Gstreamer (or by plugins for it) to be added to
Audacity relatively easily. This is something we hope to make modular,
so that it doesn't need a complete new build of audacity to use new
gstreamer plug-ins, and every download of Audacity doesn't have to ship
with every possible codec library.
Are there really codecs that are supported by Gstreamer, but not by
FFmpeg?
I dont know, is there a list of codecs which Gstreamer supports
somewhere ?

[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus
Benjamin Drung
2014-05-23 21:23:17 UTC
Permalink
Hi Michael,
Post by Michael Niedermayer
Post by Benjamin Drung
I like to commit your
work to the Audacity SVN so that we have both - support for FFmpeg and
Gstreamer.
that sounds great
I committed your code to the Audacity SVN with your name in
Signed-off-by, because I failed to find a git-am equivalent to preserve
the committer and date. Thanks for your work.

While committing, I made some small indentation adjustments. Audacity
uses 3 spaces for indentation and some of your changes used 4 spaces. I
merged your debug fprintf removal into the respective commit. I also
committed my libav 9 support patch.
Post by Michael Niedermayer
Post by Benjamin Drung
2) I can't export audio as mp4. Neither as mp4 export, nor as custom
$ ffmpeg -formats 2>/dev/null | grep mp4
D mov,mp4,m4a,3gp,3g2,mj2 QuickTime / MOV
E mp4 MP4 (MPEG-4 Part 14)
hmmm, what do you mean by "mp4" ?
there are alot of audio codecs that can be stored in mp4, for example
aac, mp3, vorbis, also there are multiple ways to encode aac, libfaac
ffmpegs native encoder and a few others ...
I tried a few things and found a few bugs (which i fixed) but iam
not convinced i fixed the issue you describe
Sorry. My description was imprecise and incorrectly (m4a instead of
mp4). I was talking about File -> Export Audio... -> "M4A (AAC) Files
(FFmpeg)". When selecting this format, the exported file has 0 bytes
content. Selecting "Custom FFmpeg Export" and then "mp4" format and
"aac" codec, the result will be the same (empty exported file). The same
applies for the wav format with pcm_s16le codec.
--
Benjamin Drung
Debian & Ubuntu Developer
Vaughan Johnson
2014-05-24 03:22:57 UTC
Permalink
Thanks to both of you!

- V
Post by Benjamin Drung
Hi Michael,
Post by Michael Niedermayer
Post by Benjamin Drung
I like to commit your
work to the Audacity SVN so that we have both - support for FFmpeg and
Gstreamer.
that sounds great
I committed your code to the Audacity SVN with your name in
Signed-off-by, because I failed to find a git-am equivalent to preserve
the committer and date. Thanks for your work.
While committing, I made some small indentation adjustments. Audacity
uses 3 spaces for indentation and some of your changes used 4 spaces. I
merged your debug fprintf removal into the respective commit. I also
committed my libav 9 support patch.
Post by Michael Niedermayer
Post by Benjamin Drung
2) I can't export audio as mp4. Neither as mp4 export, nor as custom
$ ffmpeg -formats 2>/dev/null | grep mp4
D mov,mp4,m4a,3gp,3g2,mj2 QuickTime / MOV
E mp4 MP4 (MPEG-4 Part 14)
hmmm, what do you mean by "mp4" ?
there are alot of audio codecs that can be stored in mp4, for example
aac, mp3, vorbis, also there are multiple ways to encode aac, libfaac
ffmpegs native encoder and a few others ...
I tried a few things and found a few bugs (which i fixed) but iam
not convinced i fixed the issue you describe
Sorry. My description was imprecise and incorrectly (m4a instead of
mp4). I was talking about File -> Export Audio... -> "M4A (AAC) Files
(FFmpeg)". When selecting this format, the exported file has 0 bytes
content. Selecting "Custom FFmpeg Export" and then "mp4" format and
"aac" codec, the result will be the same (empty exported file). The same
applies for the wav format with pcm_s16le codec.
Gale Andrews
2014-05-24 09:03:40 UTC
Permalink
|
Benjamin Drung
2014-05-24 11:13:11 UTC
Permalink
|
Michael Niedermayer
2014-05-24 15:44:21 UTC
Permalink
Post by Benjamin Drung
Hi Michael,
Post by Michael Niedermayer
Post by Benjamin Drung
I like to commit your
work to the Audacity SVN so that we have both - support for FFmpeg and
Gstreamer.
that sounds great
I committed your code to the Audacity SVN with your name in
Signed-off-by, because I failed to find a git-am equivalent to preserve
the committer and date. Thanks for your work.
While committing, I made some small indentation adjustments. Audacity
uses 3 spaces for indentation and some of your changes used 4 spaces. I
merged your debug fprintf removal into the respective commit. I also
committed my libav 9 support patch.
Post by Michael Niedermayer
Post by Benjamin Drung
2) I can't export audio as mp4. Neither as mp4 export, nor as custom
$ ffmpeg -formats 2>/dev/null | grep mp4
D mov,mp4,m4a,3gp,3g2,mj2 QuickTime / MOV
E mp4 MP4 (MPEG-4 Part 14)
hmmm, what do you mean by "mp4" ?
there are alot of audio codecs that can be stored in mp4, for example
aac, mp3, vorbis, also there are multiple ways to encode aac, libfaac
ffmpegs native encoder and a few others ...
I tried a few things and found a few bugs (which i fixed) but iam
not convinced i fixed the issue you describe
Sorry. My description was imprecise and incorrectly (m4a instead of
mp4). I was talking about File -> Export Audio... -> "M4A (AAC) Files
(FFmpeg)". When selecting this format, the exported file has 0 bytes
content. Selecting "Custom FFmpeg Export" and then "mp4" format and
"aac" codec, the result will be the same (empty exported file).X
This is likely due to AVCodecContext.strict_std_compliance not being
set so as to allow experimental encoders and your installed
ffmpeg/libavcodec not being build with any non experimental aac
encoder

Theres probably a error printed to the log that indicates if its that
or something else.

not sure which is the preferred way to fix this, maybe adding a
way to the GUI to allow the user to set the value for
strict_std_compliance. Or possibly to always set it so experimental
codecs are used when selected ...
Post by Benjamin Drung
The same
applies for the wav format with pcm_s16le codec.
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA
Gale Andrews
2014-05-24 16:40:15 UTC
Permalink
|
Michael Niedermayer
2014-05-24 18:12:36 UTC
Permalink
On Sat, May 24, 2014 at 05:40:15PM +0100, Gale Andrews wrote:
Gale (Audacity Team)
2014-05-25 23:37:31 UTC
Permalink
Re: https://code.google.com/p/audacity/source/detail?r=13135

@Benjamin: Does this mean that if Audacity is still released with FFmpeg
support
enabled, Win/Mac users wanting to use FFmpeg dynamic loading will be
mandated
to find a new FFmpeg installer? We currently recommend them to use an
installer
for FFmpeg 0.6.2.

And your commits to support "older" FFmpeg imply support for 0.8 to 2.2.2
inclusive?


Gale



--
View this message in context: http://audacity.238276.n2.nabble.com/Re-Libav-user-Requesting-help-to-port-Audacity-to-recent-FFmpeg-tp7561837p7561957.html
Sent from the audacity-devel mailing list archive at Nabble.com.
Gale (Audacity Team)
2014-05-26 00:23:10 UTC
Permalink
On Win 7 x64, building current HEAD r13136, Release configuration, I get this
error:

26>ExportFFmpeg.cpp
26>..\..\..\src\export\ExportFFmpeg.cpp(347) : error C3861: 'snprintf':
identifier not found



Gale




--
View this message in context: http://audacity.238276.n2.nabble.com/Re-Libav-user-Requesting-help-to-port-Audacity-to-recent-FFmpeg-tp7561837p7561958.html
Sent from the audacity-devel mailing list archive at Nabble.com.
Benjamin Drung
2014-05-26 22:28:49 UTC
Permalink
Post by Gale (Audacity Team)
On Win 7 x64, building current HEAD r13136, Release configuration, I get this
26>ExportFFmpeg.cpp
identifier not found
Can you test if adding this include to src/export/ExportFFmpeg.cpp fixes
the build failure:

#include <stdio.h>
--
Benjamin Drung
Debian & Ubuntu Developer
Gale (Audacity Team)
2014-05-26 23:22:07 UTC
Permalink
Post by Benjamin Drung
Post by Gale (Audacity Team)
On Win 7 x64, building current HEAD r13136, Release configuration, I get this
26>ExportFFmpeg.cpp
identifier not found
Can you test if adding this include to src/export/ExportFFmpeg.cpp fixes
#include <stdio.h>
I wasn't sure where to add that, but adding it either at the top of the
includes
or above the wx includes doesn't prevent the error.


Gale



--
View this message in context: http://audacity.238276.n2.nabble.com/Re-Libav-user-Requesting-help-to-port-Audacity-to-recent-FFmpeg-tp7561837p7561970.html
Sent from the audacity-devel mailing list archive at Nabble.com.
Martyn Shaw
2014-05-26 23:30:37 UTC
Permalink
I think we need a conditional
#define snprintf _snprintf
somewhere for win, as elsewhere in the code.

I've no idea where it would be best placed.

HTH
Martyn
Post by Gale (Audacity Team)
Post by Benjamin Drung
Post by Gale (Audacity Team)
On Win 7 x64, building current HEAD r13136, Release configuration, I get this
26>ExportFFmpeg.cpp
identifier not found
Can you test if adding this include to src/export/ExportFFmpeg.cpp fixes
#include <stdio.h>
I wasn't sure where to add that, but adding it either at the top of the
includes
or above the wx includes doesn't prevent the error.
Gale
--
View this message in context: http://audacity.238276.n2.nabble.com/Re-Libav-user-Requesting-help-to-port-Audacity-to-recent-FFmpeg-tp7561837p7561970.html
Sent from the audacity-devel mailing list archive at Nabble.com.
------------------------------------------------------------------------------
The best possible search technologies are now affordable for all companies.
Download your FREE open source Enterprise Search Engine today!
Our experts will assist you in its installation for $59/mo, no commitment.
Test it for FREE on our Cloud platform anytime!
http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Benjamin Drung
2014-05-31 14:45:31 UTC
Permalink
I committed the conditional define statement in r13171 in
ExportFFmpeg.cpp just below the includes. That's probably not the best
place. When someone has a better place, please let us know.

Cheers,
Benjamin
Post by Martyn Shaw
I think we need a conditional
#define snprintf _snprintf
somewhere for win, as elsewhere in the code.
I've no idea where it would be best placed.
HTH
Martyn
Post by Gale (Audacity Team)
Post by Benjamin Drung
Post by Gale (Audacity Team)
On Win 7 x64, building current HEAD r13136, Release configuration, I get this
26>ExportFFmpeg.cpp
identifier not found
Can you test if adding this include to src/export/ExportFFmpeg.cpp fixes
#include <stdio.h>
I wasn't sure where to add that, but adding it either at the top of the
includes
or above the wx includes doesn't prevent the error.
Gale
Benjamin Drung
2014-05-26 22:21:25 UTC
Permalink
Post by Gale (Audacity Team)
Re: https://code.google.com/p/audacity/source/detail?r=13135
@Benjamin: Does this mean that if Audacity is still released with FFmpeg
support
enabled, Win/Mac users wanting to use FFmpeg dynamic loading will be
mandated
to find a new FFmpeg installer? We currently recommend them to use an
installer
for FFmpeg 0.6.2.
Yes, FFmpeg 0.6.2 won't be supported anymore. Neither FFmpeg nor libav
support this version anymore. So we should not invest time to support it
any longer.
Post by Gale (Audacity Team)
And your commits to support "older" FFmpeg imply support for 0.8 to 2.2.2
inclusive?
The changes from Michael Niedermayer got Audacity working with FFmpeg
2.2/svn head, but broke support for older versions. The commits to
support older FFmpeg versions are there for making Audacity work with
libav 0.8, but the changes are not enough, yet. The builds still fail on
Ubuntu 12.04 [1].

The ideal plan is to support libav >= 0.8 and FFmpeg >= 1.2 up to recent
svn checkouts of both project. The current status is as follows:

FFmpeg 1.2 - should build (not tested)
FFmpeg 2.1 - should build (not tested)
FFmpeg 2.2 - builds
FFmpeg svn - builds (according to Michael)
libav 0.8 - does not build
libav 9 - builds [2]
libav 10 - does not build IIRC
libav svn - probably the same as libav 10

[1] https://code.launchpad.net/~audacity-team/+recipe/audacity-daily.quantal
[2] https://code.launchpad.net/~audacity-team/+recipe/daily
--
Benjamin Drung
Debian & Ubuntu Developer
Benjamin Drung
2014-05-27 22:41:45 UTC
Permalink
|
Michael Niedermayer
2014-05-28 02:59:15 UTC
Permalink
Benjamin Drung
2014-05-29 16:38:45 UTC
Permalink
Richard Ash
2014-05-21 21:21:14 UTC
Permalink
On Tue, 20 May 2014 23:41:53 +0200
Post by Benjamin Drung
This also has the benefit of allowing (in principal) any other
codecs which are supported in Gstreamer (or by plugins for it) to
be added to Audacity relatively easily. This is something we hope
to make modular, so that it doesn't need a complete new build of
audacity to use new gstreamer plug-ins, and every download of
Audacity doesn't have to ship with every possible codec library.
Are there really codecs that are supported by Gstreamer, but not by
FFmpeg?
Probably not (other than transiently). But there are some which
Audacity doesn't have, and which not a patent risk (e.g. Ogg Opus).
currently, anyone concerned about (for example) AAC patents has problems
getting Ogg Opus. There has also been a patent licensed MP3 encoder for
Gstreamer in the past (aimed at corporate users) and there is active
work to expose the GPU on the raspberry pi as gstreamer component
(making hardware acceleration possible).

So it's not just about absolute codec range, but also pick and choose
flexibility.

I think I found why it didn't work for me - I seem to have been running
the wrong binary, not the one I was compiling.

Richard
Richard Ash
2014-05-20 08:14:33 UTC
Permalink
On Wed, 14 May 2014 19:27:38 +0200
That's why I send this mail to this mailing list to request help. Is
there anyone who has the time and skill to help porting Audacity to
the latest FFmpeg API version?
[1] http://bugzilla.audacityteam.org/show_bug.cgi?id=606
I think I'm right in saying that no-one on the audacity-devel list was
specifically aware of this work/request (or I might have said something
earlier).

As a result of this problem, one of the Audacity contributors, Leyland
Lucius, has been perusing the use of Gstreamer as an abstraction layer
for ffmpeg. This work has recently arrived in Audacity SVN, so you
should be able to see where it is at (it isn't working for me, but I
don't think it's Leyland's fault).

The rationale for doing this is that the Gstreamer 1.0 API is much more
stable than the libAV one, and there is an (actively maintained)
gst-plugin-libav which provides the functionality of libAV through that
API. Thus the problem of providing up-to-date builds of libAV is
reduced, and an abstraction layer is provided.

This also has the benefit of allowing (in principal) any other codecs
which are supported in Gstreamer (or by plugins for it) to be added to
Audacity relatively easily. This is something we hope to make modular,
so that it doesn't need a complete new build of audacity to use new
gstreamer plug-ins, and every download of Audacity doesn't have to ship
with every possible codec library.



Richard
Martyn Shaw
2014-05-21 00:39:46 UTC
Permalink
Thanks Richard, I think you have made a good summary here.

Audacity is attempting to make itself independent of the changes in
libav and ffmpeg by using Gstreamer as a third-party. I support that
(for now at least). We want the functionality without the hassle.

TTFN
Martyn
On Wed, 14 May 2014 19:27:38 +0200
That's why I send this mail to this mailing list to request help. Is
there anyone who has the time and skill to help porting Audacity to
the latest FFmpeg API version?
[1] http://bugzilla.audacityteam.org/show_bug.cgi?id=606
I think I'm right in saying that no-one on the audacity-devel list was
specifically aware of this work/request (or I might have said something
earlier).
As a result of this problem, one of the Audacity contributors, Leyland
Lucius, has been perusing the use of Gstreamer as an abstraction layer
for ffmpeg. This work has recently arrived in Audacity SVN, so you
should be able to see where it is at (it isn't working for me, but I
don't think it's Leyland's fault).
The rationale for doing this is that the Gstreamer 1.0 API is much more
stable than the libAV one, and there is an (actively maintained)
gst-plugin-libav which provides the functionality of libAV through that
API. Thus the problem of providing up-to-date builds of libAV is
reduced, and an abstraction layer is provided.
This also has the benefit of allowing (in principal) any other codecs
which are supported in Gstreamer (or by plugins for it) to be added to
Audacity relatively easily. This is something we hope to make modular,
so that it doesn't need a complete new build of audacity to use new
gstreamer plug-ins, and every download of Audacity doesn't have to ship
with every possible codec library.
Richard
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Michael Niedermayer
2014-05-21 13:26:21 UTC
Permalink
Post by Martyn Shaw
Thanks Richard, I think you have made a good summary here.
Audacity is attempting to make itself independent of the changes in
libav and ffmpeg by using Gstreamer as a third-party. I support that
(for now at least). We want the functionality without the hassle.
understood, though about the "mess" some of the changes in the API
where needed so the codec can give you a buffer of the right size
instead of failing if the one you allocated was too small,
You wouldnt want to keep using an API that has such limitations,
and thats also just a one time fix, once that part of the API
is fixed it wont need to be fixed again.

And then your interface code to ffmpeg was and is alot more complex
than needed, for example the whole use of url protocol wasnt
needed (which was one thing that needed an update API wise and yes
this one resulted out of libav-ffmpeg fork mess, there was no
reason to make that API private)
but then again audacity had no need to use any of this api, and the
code is simpler without using it as well

Then there was the ffmpeg format probing code in audacity, i dont
understand why this was put there, the code is alot simpler without
it and ffmpeg will do the probing for you without that code.
Ive removed that too on the github clone and that change isnt api
update related it was just simplifying the audacity-ffmpeg interface
code.
And i suspect theres alot more that can be simplified in it, and the
amount of "api-hassle" there would be in the future should be alot
less when the interface is using only what it actually needs to
Post by Martyn Shaw
TTFN
Martyn
On Wed, 14 May 2014 19:27:38 +0200
That's why I send this mail to this mailing list to request help. Is
there anyone who has the time and skill to help porting Audacity to
the latest FFmpeg API version?
[1] http://bugzilla.audacityteam.org/show_bug.cgi?id=606
I think I'm right in saying that no-one on the audacity-devel list was
specifically aware of this work/request (or I might have said something
earlier).
As a result of this problem, one of the Audacity contributors, Leyland
Lucius, has been perusing the use of Gstreamer as an abstraction layer
for ffmpeg. This work has recently arrived in Audacity SVN, so you
should be able to see where it is at (it isn't working for me, but I
don't think it's Leyland's fault).
The rationale for doing this is that the Gstreamer 1.0 API is much more
stable than the libAV one, and there is an (actively maintained)
gst-plugin-libav which provides the functionality of libAV through that
API. Thus the problem of providing up-to-date builds of libAV is
reduced, and an abstraction layer is provided.
This also has the benefit of allowing (in principal) any other codecs
which are supported in Gstreamer (or by plugins for it) to be added to
Audacity relatively easily. This is something we hope to make modular,
so that it doesn't need a complete new build of audacity to use new
gstreamer plug-ins, and every download of Audacity doesn't have to ship
with every possible codec library.
Richard
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire
Gale Andrews
2014-05-22 03:57:43 UTC
Permalink
|
Michael Niedermayer
2014-05-23 05:01:44 UTC
Permalink
Hi

On Thu, May 22, 2014 at 04:57:43AM +0100, Gale Andrews wrote:
Continue reading on narkive:
Loading...