[Libav-user] Requesting help to port Audacity to recent FFmpeg

[Benjamin Drung]

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

[Michael Niedermayer]

This post might be inappropriate. Click to display it.

[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.

[Michael Niedermayer]

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 Niedermayer]

Hi

On Wed, 14 May 2014 19:27:38 +0200

Post by Benjamin Drung
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 Niedermayer]

Hi

On Tue, May 20, 2014 at 11:41:53PM +0200, Benjamin Drung wrote:
[...]

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 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 ?


[...]

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

fixed

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 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 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 Niedermayer]

Post by Benjamin Drung
Hi Michael,

Post by Michael Niedermayer

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

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.

[...]

[Benjamin Drung]

Hi Michael,

Post by Michael Niedermayer

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

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.

[wm4]

On Tue, 20 May 2014 19:17:07 +0200

Post by Michael Niedermayer
Hi

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 ...

Definitely there would be interest in such a thing all over the place.
IMO the main problem with libavcodec etc. is that they provide a very
low-level API. This is fine for API users which need it, but for
everyone else this causes a load of complexity which would otherwise
not be needed. For example, not many API users care about the
separation of decoder and demuxer, but on the other hand connecting
these can be hard work. Likewise, writing code to convert the output
using libswscale etc. is additional work that could be avoided by a
high-level API.

Here's some quick brainstorming what a high-level API could look like
in the decoding case:

av_decoder *dec = av_decoder_open("somefile.mp3");
av_decoder_set_audio_format(dec, AV_SAMPLE_FMT_S16);
av_decoder_set_audio_rate(dec, 48000);
av_decoder_set_audio_channels(dec, AV_CH_LAYOUT_STEREO);
av_decoder_set_audio_filters(dec, "aecho,earwax");
// Decode all data from stream 0
while ((AVFrame *data = av_decoder_decode(dec, 0)) {
do_something(data->data[0], data->nb_samples);
}

This is all what many API users will need. Now imagine how much (broken)
boilerplate you'd have to write to get this, and how much of it will
break with future API changes.

Obviously this example is naive and would need some refinement, and I'm
not sure how encoding would work; I'm just saying it can be done.

In particular, I think there should be a high interest to get people
away from gstreamer - mostly because it turns out that gstreamer's
ffmpeg wrapper is pretty buggy overall, and users should be _not_
forced to use that just for the sake for a more stable API.

[Benjamin Drung]

Hi Michael,

first, let me thank you for your work.

Post by Michael Niedermayer
Hi

On Wed, 14 May 2014 19:27:38 +0200

Post by Benjamin Drung
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

[Richard Ash]

On Tue, 20 May 2014 23:41:53 +0200

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]

On Wed, 14 May 2014 19:27:38 +0200

Post by Benjamin Drung
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

[Michael Niedermayer]

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

TTFN
Martyn

On Wed, 14 May 2014 19:27:38 +0200

Post by Benjamin Drung
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 Niedermayer]

Hi

On Thu, May 22, 2014 at 04:57:43AM +0100, Gale Andrews wrote:

[Gale Andrews]

|

[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.

TTFN
Martyn

On Wed, 14 May 2014 19:27:38 +0200

Post by Benjamin Drung
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