Thread: [Audacity-devel] building audacity with ffmpeg 0.11.1 - started patching ...
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: David T. <dt...@ii...> - 2012-09-10 13:37:05
|
Hi, I've started the process of updating audacity to suit current upstream ffmpeg (which will be in Fedora/RPM Fusion 18 due during November). It's definitely slow going. If someone has already done this or is working on it, please let me know, so that we aren't duplicating effort ? Currently, I know it's broken for F17 (ffmpeg-0.10.x), and F18 (ffpmeg-0.11.1). The patches are not really ready for consumption, however, if someone is willing to review before I potentially head too far down the wrong path, please also let me know ? Patches are attached: 1. updates lib-src/ffmpeg/ folder with upstream ffmpeg-0.11.1 headers (huge) 2. updates src/FFmpeg.h to start to get compile with the above. (so far) Cheers, David. |
From: Richard A. <ri...@au...> - 2012-09-10 21:24:31
|
On Mon, 2012-09-10 at 23:36 +1000, David Timms wrote: > Hi, I've started the process of updating audacity to suit current > upstream ffmpeg (which will be in Fedora/RPM Fusion 18 due during November). > > It's definitely slow going. If someone has already done this or is > working on it, please let me know, so that we aren't duplicating effort ? > > Currently, I know it's broken for F17 (ffmpeg-0.10.x), and F18 > (ffpmeg-0.11.1). > The patches are not really ready for consumption, however, if someone is > willing to review before I potentially head too far down the wrong path, > please also let me know ? > > Patches are attached: > 1. updates lib-src/ffmpeg/ folder with upstream ffmpeg-0.11.1 headers (huge) > 2. updates src/FFmpeg.h to start to get compile with the above. (so far) Most distributions have patches to work with ffmpeg-0.10. The reason they aren't easy to upstream is that no-one builds ffmpeg for Windows and Mac regularly, so we have to have source compatibility with (currently) a 0.6 series library on those platforms plus a range of versions in distros. Most of the patches I see in distros fix one specific ffmpeg version and break all others, which makes upstreaming them a non-option. This would obviously be made easier if someone was able to provide newer (stable release) builds of ffmpeg to reduce the version range we have to cover. Richard |
From: Gale A. <ga...@au...> - 2012-09-13 20:39:01
|
| From Richard Ash <ri...@au...> | Mon, 10 Sep 2012 22:24:16 +0100 | Subject: [Audacity-devel] building audacity with ffmpeg 0.11.1 - started patching ... > On Mon, 2012-09-10 at 23:36 +1000, David Timms wrote: > > Hi, I've started the process of updating audacity to suit current > > upstream ffmpeg (which will be in Fedora/RPM Fusion 18 due during November). > > > > It's definitely slow going. If someone has already done this or is > > working on it, please let me know, so that we aren't duplicating effort ? > > > > Currently, I know it's broken for F17 (ffmpeg-0.10.x), and F18 > > (ffpmeg-0.11.1). > > The patches are not really ready for consumption, however, if someone is > > willing to review before I potentially head too far down the wrong path, > > please also let me know ? > > > > Patches are attached: > > 1. updates lib-src/ffmpeg/ folder with upstream ffmpeg-0.11.1 headers (huge) > > 2. updates src/FFmpeg.h to start to get compile with the above. (so far) > > Most distributions have patches to work with ffmpeg-0.10. The reason > they aren't easy to upstream is that no-one builds ffmpeg for Windows > and Mac regularly, so we have to have source compatibility with > (currently) a 0.6 series library on those platforms plus a range of > versions in distros. Most of the patches I see in distros fix one > specific ffmpeg version and break all others, which makes upstreaming > them a non-option. > > This would obviously be made easier if someone was able to provide newer > (stable release) builds of ffmpeg to reduce the version range we have to > cover. FWIW I built the 0.8.12 and 0.9.2 "stable" releases from: http://ffmpeg.org/download.html using MinGW, also also built FFmpeg revision 26400 which is a bit later than FFmpeg 0.6.2: libavcodec version: 52.108.0 libavformat version: 52.93.0 libavutil version: 50.36.0. Audacity on Windows works OK with r26400 when loading it from the Libraries Preferences, but doesn't seem to recognise 0.8.12 or 0.9.2 loaded that way. The major F,C,U numbers are higher with 0.8.12 and 0.9.2. Does more have to be done to our own code first? Isn't trying to leverage ffmpeg.exe the better option? The Audacity command-line exporter never seems to have an issue using latest git FFmpeg even on Windows. Gale |
From: Benjamin D. <bd...@ub...> - 2012-09-13 21:36:26
Attachments:
signature.asc
|
Am Donnerstag, den 13.09.2012, 21:38 +0100 schrieb Gale Andrews: > Isn't trying to leverage ffmpeg.exe the better option? The Audacity > command-line exporter never seems to have an issue using latest > git FFmpeg even on Windows. I am against using the command-line exporter if the library usage is removed. -- Benjamin Drung Debian & Ubuntu Developer |
From: Gale (A. Team) <ga...@au...> - 2012-09-15 05:38:11
|
"Benjamin Drung-2" wrote: Am Donnerstag, den 13.09.2012, 21:38 +0100 schrieb Gale Andrews: >> Isn't trying to leverage ffmpeg.exe the better option? The Audacity >> command-line exporter never seems to have an issue using latest >> git FFmpeg even on Windows. > I am against using the command-line exporter if the library usage is > removed. The suggestion (which has been made before on this list) was that users would still be able to import and export as now using the import and export dialogues and the export options, but we'd be using whatever version of ffmpeg.exe or equivalent the user happened to point Audacity to, in the hope of freeing ourselves from most of the FFmpeg version headaches. I imagine the Libraries Preferences could still be used to choose the ffmpeg.exe version. Do you feel any happier with that? Gale -- View this message in context: http://audacity.238276.n2.nabble.com/building-audacity-with-ffmpeg-0-11-1-started-patching-tp7556204p7556216.html Sent from the audacity-devel mailing list archive at Nabble.com. |
From: David T. <dt...@ii...> - 2012-09-15 23:02:26
|
On 15/09/12 15:38, Gale (Audacity Team) wrote: > "Benjamin Drung-2" wrote: >> I am against using the command-line exporter if the library usage is >> removed. > The suggestion (which has been made before on this list) was that users > would still be able to import and export as now using the import and export > dialogues and the export options, but we'd be using whatever version of > ffmpeg.exe or equivalent the user happened to point Audacity to, in the > hope of freeing ourselves from most of the FFmpeg version headaches. What other dis/advantages to using external executable ffmpeg ? slower ? no progress UI ? need bigger temp space ? I have never used the external (did not know that it existed), so just guessing ? David. |
From: Gale A. <ga...@au...> - 2012-09-16 22:41:01
|
| From David Timms <dt...@ii...> | Sun, 16 Sep 2012 09:02:16 +1000 | Subject: [Audacity-devel] building audacity with ffmpeg 0.11.1 - started patching ... > On 15/09/12 15:38, Gale (Audacity Team) wrote: > > "Benjamin Drung-2" wrote: > >> I am against using the command-line exporter if the library usage is > >> removed. > > The suggestion (which has been made before on this list) was that users > > would still be able to import and export as now using the import and export > > dialogues and the export options, but we'd be using whatever version of > > ffmpeg.exe or equivalent the user happened to point Audacity to, in the > > hope of freeing ourselves from most of the FFmpeg version headaches. > > What other dis/advantages to using external executable ffmpeg ? > slower ? This bug suggest the command-line exporter is slower than using the dynamic library, but I have not tested it in a while: http://bugzilla.audacityteam.org/show_bug.cgi?id=340 . > no progress UI ? That depends if we can implement one. I believe other apps that use .exe encoders e.g. SUPER Player have progress bars. > need bigger temp space ? Don't know. What problem do you have in mind? Gale > I have never used the external (did not know that it existed), so just > guessing ? > > David. |
From: Benjamin D. <bd...@ub...> - 2012-09-19 12:18:53
Attachments:
signature.asc
|
Am Freitag, den 14.09.2012, 22:38 -0700 schrieb Gale (Audacity Team): > "Benjamin Drung-2" wrote: > Am Donnerstag, den 13.09.2012, 21:38 +0100 schrieb Gale Andrews: > >> Isn't trying to leverage ffmpeg.exe the better option? The Audacity > >> command-line exporter never seems to have an issue using latest > >> git FFmpeg even on Windows. > > I am against using the command-line exporter if the library usage is > > removed. > The suggestion (which has been made before on this list) was that users > would still be able to import and export as now using the import and export > dialogues and the export options, but we'd be using whatever version of > ffmpeg.exe or equivalent the user happened to point Audacity to, in the > hope of freeing ourselves from most of the FFmpeg version headaches. > > I imagine the Libraries Preferences could still be used to choose the > ffmpeg.exe version. > > Do you feel any happier with that? No. The idea of using the command-line tool seems to me like adding an additional layer that brings new problems while solving one. Besides the slower export, the progress UI, these topics came to my mind: 1) How do you handle errors? You need to parse the textual output of FFmpeg, which can be everything. 2) libav forked FFmpeg and renamed the binary. libav deprecated the ffmpeg binary (= ffmpeg.exe on Windows). Calling the deprecated ffmpeg binary from libav, a warning will be printed. -- Benjamin Drung Debian & Ubuntu Developer |
From: Gale A. <ga...@au...> - 2012-09-19 22:05:25
|
| From Benjamin Drung <bd...@ub...> | Wed, 19 Sep 2012 14:18:39 +0200 | Subject: [Audacity-devel] building audacity with ffmpeg 0.11.1 - started patching ... > Am Freitag, den 14.09.2012, 22:38 -0700 schrieb Gale (Audacity Team): > > "Benjamin Drung-2" wrote: > > Am Donnerstag, den 13.09.2012, 21:38 +0100 schrieb Gale Andrews: > > >> Isn't trying to leverage ffmpeg.exe the better option? The Audacity > > >> command-line exporter never seems to have an issue using latest > > >> git FFmpeg even on Windows. > > > I am against using the command-line exporter if the library usage is > > > removed. > > The suggestion (which has been made before on this list) was that users > > would still be able to import and export as now using the import and export > > dialogues and the export options, but we'd be using whatever version of > > ffmpeg.exe or equivalent the user happened to point Audacity to, in the > > hope of freeing ourselves from most of the FFmpeg version headaches. > > > > I imagine the Libraries Preferences could still be used to choose the > > ffmpeg.exe version. > > > > Do you feel any happier with that? > > No. The idea of using the command-line tool seems to me like adding an > additional layer that brings new problems while solving one. It's suggested as a replacement for the dynamic libs, not additional. > Besides the slower export That remains to be proved, though it would be a major objection if proved. > the progress UI these topics came to my mind: > > 1) How do you handle errors? You need to parse the textual output of > FFmpeg, which can be everything. Users will not be entering command-line strings, rather their "Options" settings for the format will determine what gets passed to the encoder. So a) there should not be many errors and b) other GUI apps that use FFmpeg.exe seem to manage to throw a sensible error if open or encoding fails. > 2) libav forked FFmpeg and renamed the binary. libav deprecated the > ffmpeg binary (= ffmpeg.exe on Windows). Calling the deprecated ffmpeg > binary from libav, a warning will be printed. I don't see this error in the output on Windows using (external program) pointed to latest git FFmpeg.exe. Is there an equivalent libav binary we should be using instead? I'm not supposing this suggestion is other than a lot of work, but Leland's initial reaction was that this was feasible. The potential prize for saving of work in the long term seems quite significant to me. While we are at it, we could use FFmpeg for MP3 exports so that users only have to download one optional library. Even the Windows and Mac users are starting to complain that the recommended download of FFmpeg for use in Audacity is years out-of-date. Gale |
From: Benjamin D. <bd...@ub...> - 2012-09-19 22:50:11
Attachments:
signature.asc
|
Am Mittwoch, den 19.09.2012, 23:05 +0100 schrieb Gale Andrews: > | From Benjamin Drung <bd...@ub...> > | Wed, 19 Sep 2012 14:18:39 +0200 > | Subject: [Audacity-devel] building audacity with ffmpeg 0.11.1 - started patching ... > > Am Freitag, den 14.09.2012, 22:38 -0700 schrieb Gale (Audacity Team): > > > "Benjamin Drung-2" wrote: > > > Am Donnerstag, den 13.09.2012, 21:38 +0100 schrieb Gale Andrews: > > > >> Isn't trying to leverage ffmpeg.exe the better option? The Audacity > > > >> command-line exporter never seems to have an issue using latest > > > >> git FFmpeg even on Windows. > > > > I am against using the command-line exporter if the library usage is > > > > removed. > > > The suggestion (which has been made before on this list) was that users > > > would still be able to import and export as now using the import and export > > > dialogues and the export options, but we'd be using whatever version of > > > ffmpeg.exe or equivalent the user happened to point Audacity to, in the > > > hope of freeing ourselves from most of the FFmpeg version headaches. > > > > > > I imagine the Libraries Preferences could still be used to choose the > > > ffmpeg.exe version. > > > > > > Do you feel any happier with that? > > > > No. The idea of using the command-line tool seems to me like adding an > > additional layer that brings new problems while solving one. > > It's suggested as a replacement for the dynamic libs, not additional. > > > > Besides the slower export > > That remains to be proved, though it would be a major objection > if proved. > > > > the progress UI these topics came to my mind: > > > > 1) How do you handle errors? You need to parse the textual output of > > FFmpeg, which can be everything. > > Users will not be entering command-line strings, rather their "Options" > settings for the format will determine what gets passed to the > encoder. So a) there should not be many errors and b) other GUI > apps that use FFmpeg.exe seem to manage to throw a sensible > error if open or encoding fails. Does these other GUI apps just pass the error message from the FFmpeg.exe to the user? Using the library gives you a tighter control about the error messages. > > 2) libav forked FFmpeg and renamed the binary. libav deprecated the > > ffmpeg binary (= ffmpeg.exe on Windows). Calling the deprecated ffmpeg > > binary from libav, a warning will be printed. > > I don't see this error in the output on Windows using (external > program) pointed to latest git FFmpeg.exe. > > Is there an equivalent libav binary we should be using instead? It's called avconv. This is what the ffmpeg binary from libav says: *** THIS PROGRAM IS DEPRECATED *** This program is only provided for compatibility and will be removed in a future release. Please use avconv instead. > I'm not supposing this suggestion is other than a lot of work, > but Leland's initial reaction was that this was feasible. > > The potential prize for saving of work in the long term seems quite > significant to me. Supporting newer FFmpeg version at compile time shouldn't be that time consuming. Supporting a different range at runtime may be more complicated. I tend to thinks about offering my help in maintaining the FFmpeg support in Audacity. > While we are at it, we could use FFmpeg for MP3 > exports so that users only have to download one optional library. Using FFmpeg for MP3 export is orthogonal to this proposed change. > Even the Windows and Mac users are starting to complain that > the recommended download of FFmpeg for use in Audacity is > years out-of-date. Where is the difference to the proposed change? The user will still have to download FFmpeg. -- Benjamin Drung Debian & Ubuntu Developer |
From: Gale A. <ga...@au...> - 2012-09-20 20:48:45
|
| From Benjamin Drung <bd...@ub...> | Thu, 20 Sep 2012 00:50:01 +0200 | Subject: [Audacity-devel] building audacity with ffmpeg 0.11.1 - started patching ... > Am Mittwoch, den 19.09.2012, 23:05 +0100 schrieb Gale Andrews: > > | From Benjamin Drung <bd...@ub...> > > | Wed, 19 Sep 2012 14:18:39 +0200 > > | Subject: [Audacity-devel] building audacity with ffmpeg 0.11.1 - started patching ... > > > Am Freitag, den 14.09.2012, 22:38 -0700 schrieb Gale (Audacity Team): > > > > "Benjamin Drung-2" wrote: > > > > Am Donnerstag, den 13.09.2012, 21:38 +0100 schrieb Gale Andrews: > > > > >> Isn't trying to leverage ffmpeg.exe the better option? The Audacity > > > > >> command-line exporter never seems to have an issue using latest > > > > >> git FFmpeg even on Windows. > > > > > I am against using the command-line exporter if the library usage is > > > > > removed. > > > > The suggestion (which has been made before on this list) was that users > > > > would still be able to import and export as now using the import and export > > > > dialogues and the export options, but we'd be using whatever version of > > > > ffmpeg.exe or equivalent the user happened to point Audacity to, in the > > > > hope of freeing ourselves from most of the FFmpeg version headaches. > > > > > > > > I imagine the Libraries Preferences could still be used to choose the > > > > ffmpeg.exe version. > > > > > > > > Do you feel any happier with that? > > > > > > No. The idea of using the command-line tool seems to me like adding an > > > additional layer that brings new problems while solving one. > > > > It's suggested as a replacement for the dynamic libs, not additional. > > > > > > > Besides the slower export > > > > That remains to be proved, though it would be a major objection > > if proved. Further to Steve's test I did my own test on Windows 7 x64 using FFmpeg version SVN-r26400 (somewhere before current FFmpeg 0.8 release). This machine is 2.4 GHz Dual Core 6 GB RAM, so more capable than the one I used to test before. Over three tests with a five-minute stereo track, using identical format options, AAC, WMA and AC3 export takes the same time or a little less using (external program) than the specific encoding option such as "AC3 Files (FFmpeg)". > > > the progress UI these topics came to my mind: > > > > > > 1) How do you handle errors? You need to parse the textual output of > > > FFmpeg, which can be everything. > > > > Users will not be entering command-line strings, rather their "Options" > > settings for the format will determine what gets passed to the > > encoder. So a) there should not be many errors and b) other GUI > > apps that use FFmpeg.exe seem to manage to throw a sensible > > error if open or encoding fails. > > Does these other GUI apps just pass the error message from the > FFmpeg.exe to the user? Using the library gives you a tighter control > about the error messages. Given the error text, my feeling is these are not literal errors parsed "as is" from FFmpeg.exe. > > I'm not supposing this suggestion is other than a lot of work, > > but Leland's initial reaction was that this was feasible. > > > > The potential prize for saving of work in the long term seems quite > > significant to me. > > Supporting newer FFmpeg version at compile time shouldn't be that time > consuming. Supporting a different range at runtime may be more > complicated. Isn't it actually quite a lot of work to keep updating for current FFmpeg while still keeping backwards compatibility (bearing in mind Windows and especially Mac recommended FFmpeg may be many versions behind)? > I tend to thinks about offering my help in maintaining the FFmpeg > support in Audacity. Thanks of course for your help. > > While we are at it, we could use FFmpeg for MP3 > > exports so that users only have to download one optional library. > > Using FFmpeg for MP3 export is orthogonal to this proposed change. Yes we could drop LAME support now (with a certain amount of work). However if we do the proposed change, doesn't it make sense to do it for only one library? > > Even the Windows and Mac users are starting to complain that > > the recommended download of FFmpeg for use in Audacity is > > years out-of-date. > > Where is the difference to the proposed change? The user will still have > to download FFmpeg. The difference is that the user could use an arbitrary version of FFmpeg (maybe a version they already had obtained in another program, so they don't need to download a different version at all). It means that Windows / Mac users (on which platforms we may not have resources to update the recommended FFmpeg version) are not compelled to always use older versions. We lose the potential problem that Windows/Mac holds back the latest FFmpeg version that Audacity can use. Gale |
From: Steve t. F. <ste...@gm...> - 2012-09-19 23:48:44
|
On 19 September 2012 23:05, Gale Andrews <ga...@au...> wrote: > > | From Benjamin Drung <bd...@ub...> > | Wed, 19 Sep 2012 14:18:39 +0200 > | Subject: [Audacity-devel] building audacity with ffmpeg 0.11.1 - started patching ... >> Am Freitag, den 14.09.2012, 22:38 -0700 schrieb Gale (Audacity Team): >> > "Benjamin Drung-2" wrote: >> > Am Donnerstag, den 13.09.2012, 21:38 +0100 schrieb Gale Andrews: >> > >> Isn't trying to leverage ffmpeg.exe the better option? The Audacity >> > >> command-line exporter never seems to have an issue using latest >> > >> git FFmpeg even on Windows. >> > > I am against using the command-line exporter if the library usage is >> > > removed. >> > The suggestion (which has been made before on this list) was that users >> > would still be able to import and export as now using the import and export >> > dialogues and the export options, but we'd be using whatever version of >> > ffmpeg.exe or equivalent the user happened to point Audacity to, in the >> > hope of freeing ourselves from most of the FFmpeg version headaches. >> > >> > I imagine the Libraries Preferences could still be used to choose the >> > ffmpeg.exe version. >> > >> > Do you feel any happier with that? >> >> No. The idea of using the command-line tool seems to me like adding an >> additional layer that brings new problems while solving one. > > It's suggested as a replacement for the dynamic libs, not additional. > > >> Besides the slower export > > That remains to be proved, though it would be a major objection > if proved. I've just tried a few tests on Debian (Squeeze) comparing the speed of export using Audacity's built-in FFMpeg export options vs using FFMpeg as an "external encoder". Surprisingly, the "external encoder" option is around 3 to 4 times faster than the built in FFMpeg export options. Also, exporting as MP3 with "Custom FFMpeg Export" is like watching paint dry, whereas exporting in an identical MP3 format with FFMpeg as an external encoder is a fraction quicker than the normal (LAME) MP3 export. Steve > > >> the progress UI these topics came to my mind: >> >> 1) How do you handle errors? You need to parse the textual output of >> FFmpeg, which can be everything. > > Users will not be entering command-line strings, rather their "Options" > settings for the format will determine what gets passed to the > encoder. So a) there should not be many errors and b) other GUI > apps that use FFmpeg.exe seem to manage to throw a sensible > error if open or encoding fails. > > >> 2) libav forked FFmpeg and renamed the binary. libav deprecated the >> ffmpeg binary (= ffmpeg.exe on Windows). Calling the deprecated ffmpeg >> binary from libav, a warning will be printed. > > I don't see this error in the output on Windows using (external > program) pointed to latest git FFmpeg.exe. > > Is there an equivalent libav binary we should be using instead? > > I'm not supposing this suggestion is other than a lot of work, > but Leland's initial reaction was that this was feasible. > > The potential prize for saving of work in the long term seems quite > significant to me. While we are at it, we could use FFmpeg for MP3 > exports so that users only have to download one optional library. > > Even the Windows and Mac users are starting to complain that > the recommended download of FFmpeg for use in Audacity is > years out-of-date. > > > > > Gale > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel |
From: David T. <dt...@ii...> - 2012-09-24 22:24:36
Attachments:
audacity-2.0.2-ffmpeg-0.11.1-src-mods5.patch
audacity-2.0.2-ffmpeg-0.11.1-src-mods6.patch
audacity-2.0.2-ffmpeg-0.11.1-src-mods7.patch
audacity-2.0.2-ffmpeg-0.11.1-src-mods8.patch
audacity-2.0.2-ffmpeg-0.11.1-src-mods9.patch
audacity-2.0.2-ffmpeg-0.11.1-src-mods10.patch
audacity-2.0.2-ffmpeg-0.11.1-src-mods11.patch
audacity-2.0.2-ffmpeg-0.11.1-src-mods12.patch
audacity-2.0.2-ffmpeg-0.11.1-src-mods13.patch
|
On 10/09/12 23:36, David Timms wrote: > Hi, I've started the process of updating audacity to suit current > upstream ffmpeg (which will be in Fedora/RPM Fusion 18 due during November). ... In the meantime, I have continued my changes. I currently have a series of patches (which I could roll into one if preferred, but it's sort of easier at the moment to resolve one compile error at a time). Patches are attached: audacity-2.0.2-ffmpeg-0.11.1-src-mods.patch from the first email in this thread had a problem that lead me a little astray. Use the following instead: audacity-2.0.2-ffmpeg-0.11.1-src-mods5.patch rest: audacity-2.0.2-ffmpeg-0.11.1-src-mods6.patch audacity-2.0.2-ffmpeg-0.11.1-src-mods7.patch audacity-2.0.2-ffmpeg-0.11.1-src-mods8.patch audacity-2.0.2-ffmpeg-0.11.1-src-mods9.patch audacity-2.0.2-ffmpeg-0.11.1-src-mods10.patch audacity-2.0.2-ffmpeg-0.11.1-src-mods11.patch audacity-2.0.2-ffmpeg-0.11.1-src-mods12.patch actually: some of these I added ifdef but I'm not sure what to replace the original code with at this stage. and I'm still working on/around this one: audacity-2.0.2-ffmpeg-0.11.1-src-mods13.patch The current compile errors involve: AVFormatParameters av_register_protocol /_fp URLProtocol (these are present but moved to internal rather than public API access; it's not clear what the new equivalent is) url_open_protocol /_fp URLContext url_open /_fp url_close AVMetadataTag av_metadata_set2 /_fp AVMetadata ie, all the actual file handling stuff. Any pointers welcome, if no one here has insight, I'll try one of the ffmpeg lists. Cheers, David. |
From: David T. <dt...@ii...> - 2012-09-24 22:33:04
|
On 25/09/12 08:24, David Timms wrote: > On 10/09/12 23:36, David Timms wrote: >> Hi, I've started the process of updating audacity to suit current >> upstream ffmpeg (which will be in Fedora/RPM Fusion 18 due during November). > ... > In the meantime, I have continued my changes. I currently have a series > of patches (which I could roll into one if preferred, but it's sort of > easier at the moment to resolve one compile error at a time). > > Patches are attached: ps. I've been building against Fedora 16 (earlier), 17 (ffmpeg-libs-0.10.4-2) and rawhide (ffmpeg-0.11.1) > Cheers, David. |