Thread: [Audacity-devel] Feature freeze and ffmpeg on-demand
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Michael C. <mc...@gm...> - 2010-03-08 16:10:46
|
I've been working with ffmpeg and libmad in my own projects, so I feel now is a good time to put in on-demand versions into Audacity under experimental (just as it is flac on-demand.) In theory this will not destabilize audacity - there will be no changes for example, to ImportFFMPEG.cpp with the EXPERIMENTAL_ODFFMPEG flag off, and with them on, only a few changes will be made (see ImportFlac.cpp for an example.) Ideally, for optimal code reuse, I will need to refactor some of the code in ImportFFMPEG.cpp to seperate the parts that don't touch audacity UI (e.g. the progress bar.) But for the risk of destabilization I will not do this till after we release 1.4/2.0, and just use well marked copy/paste snippets for now in OD cpp files. There is feature freeze on, and this will be respected by not changing the runtime behavior of audacity in any way. I wish to do this now because motivation is high. Furthermore, I just went through the OD code review as well and want to do it while both it and these libraries are still fresh in my head. I do not anticipate strain from other developers, except that it would be nice if they could at the new files to the other platform projects. Any objections? Michael |
From: LRN <lr...@gm...> - 2010-03-08 17:07:16
|
On 08.03.2010 19:09, Michael Chinen wrote: > Any objections? > One thing i'm concerned about is a feature that i had in mind but have not implemented yet: in theory, Audacity should accumulate log messages with level >= FFmpegShownErrorLevel (tweakable in options) and show them to user after import procedure completes (successfully or not), this way user does not have to look into debug log to see why import has failed. With OD support implemented in FFmpeg importer it is not clear when exactly "after import procedure completes" is. An adequate thing to do would be a dialog that pops up at first showable message and updates its contents with more messages as the process goes on. It should have a button that will close it and set it ignore further messages for the file being imported (or for all files being imported, in case of multiple import files). That should work reasonably well with OD, but i'm open to suggestions. Maybe displaying everything after OD is completed would be better? As for freeze/stability/whatever concerns - you can always use EXPERIMENTAL_* ifdef to separate new code. |
From: Michael C. <mc...@gm...> - 2010-03-08 19:40:51
|
On Mon, Mar 8, 2010 at 6:06 PM, LRN <lr...@gm...> wrote: > On 08.03.2010 19:09, Michael Chinen wrote: > > Any objections? > > > One thing i'm concerned about is a feature that i had in mind but have > not implemented yet: in theory, Audacity should accumulate log messages > with level >= FFmpegShownErrorLevel (tweakable in options) and show them > to user after import procedure completes (successfully or not), this way > user does not have to look into debug log to see why import has failed. > With OD support implemented in FFmpeg importer it is not clear when > exactly "after import procedure completes" is. An adequate thing to do > would be a dialog that pops up at first showable message and updates its > contents with more messages as the process goes on. It should have a > button that will close it and set it ignore further messages for the > file being imported (or for all files being imported, in case of > multiple import files). That should work reasonably well with OD, but > i'm open to suggestions. Maybe displaying everything after OD is > completed would be better? > This sounds like a good system, and would help to address at least one issue that OD would need - when the file proves not to be sample accurate seekable and we have to notify the user that we have disallowed the seeking feature. Similar to how vlc handles playback errors, perhaps? Another reason we need this is that wxDebugLog calls are not threadsafe at all and will crash if called from a non-GUI thread. As for freeze/stability/whatever concerns - you can always use > EXPERIMENTAL_* ifdef to separate new code. > I will be doing this. I'll let you know how it goes. Michael |
From: James C. <cr...@in...> - 2010-03-08 23:07:22
|
With regards feature freeze - the intent of feature freeze is to avoid getting into deeper 'code debt'. Code debt is unfinished features, code that needs tidying, code with bugs, cut-and-paste code that needs merging. Refactoring when done with adequate care and attention removes bugs rather than introducing them. The algorithms become clearer and more manifestly correct. Radical refactoring, as would be needed for plug-in API needs extreme care, but I do expect we will be doing that, even though in feature freeze. The refactoring you're talking about is or should be low risk. If you can only do your changes by cut and pasting significant quantities of code then I don't think you should go ahead. If you want to support more formats, plan to do some refactoring too so that it is done in a clean way. If you are worried about breakages, possibly start by doing the most essential refactoring, and then ask for a review? I can do review again. Although I am short of time that is something I can make time for. If it does break, then I am partly responsible.... --James. On 08/03/2010 16:09, Michael Chinen wrote: > I've been working with ffmpeg and libmad in my own projects, so I feel > now is a good time to put in on-demand versions into Audacity under > experimental (just as it is flac on-demand.) In theory this will not > destabilize audacity - there will be no changes for example, to > ImportFFMPEG.cpp with the EXPERIMENTAL_ODFFMPEG flag off, and with > them on, only a few changes will be made (see ImportFlac.cpp for an > example.) > > Ideally, for optimal code reuse, I will need to refactor some of the > code in ImportFFMPEG.cpp to seperate the parts that don't touch > audacity UI (e.g. the progress bar.) But for the risk of > destabilization I will not do this till after we release 1.4/2.0, and > just use well marked copy/paste snippets for now in OD cpp files. > > There is feature freeze on, and this will be respected by not changing > the runtime behavior of audacity in any way. I wish to do this now > because motivation is high. Furthermore, I just went through the OD > code review as well and want to do it while both it and these > libraries are still fresh in my head. I do not anticipate strain from > other developers, except that it would be nice if they could at the > new files to the other platform projects. Any objections? > > Michael |
From: Michael C. <mc...@gm...> - 2010-03-09 02:10:40
|
On Tue, Mar 9, 2010 at 12:07 AM, James Crook <cr...@in...> wrote: > With regards feature freeze - the intent of feature freeze is to avoid > getting into deeper 'code debt'. Code debt is unfinished features, code > that needs tidying, code with bugs, cut-and-paste code that needs merging. > > Refactoring when done with adequate care and attention removes bugs rather > than introducing them. The algorithms become clearer and more manifestly > correct. Radical refactoring, as would be needed for plug-in API needs > extreme care, but I do expect we will be doing that, even though in feature > freeze. The refactoring you're talking about is or should be low risk. If > you can only do your changes by cut and pasting significant quantities of > code then I don't think you should go ahead. If you want to support more > formats, plan to do some refactoring too so that it is done in a clean way. > If you are worried about breakages, possibly start by doing the most > essential refactoring, and then ask for a review? I can do review again. > Although I am short of time that is something I can make time for. If it > does break, then I am partly responsible.... > > I understand the theory behind why you are only for my commit of the code if I have already done the refactoring. Refactoring is a great idea when you have a a stable implementation. However I'm not so sure that its the best way to go before implementation. The issue is that it is not just copy and paste, but also involves editing after the paste, the details of which are not concrete before implementation. It is precisely these edit details that determine the best way to do the refactoring. It would take an extremely sharp designer to be able to visualize these details before implementation, and I have to admit that I am not one of those. The main point is that I don't know how much of the code from ImportFFMpeg will be reusable at design time, and that I'd like to be able to commit the prototype in the period it takes up to that point. I think it is worthwhile to create a working prototype using some well-marked copy/pasting/editing before making the refactoring changes, then finalize and decide exactly how and where to make the refactoring cuts into the ImportFFMpeg classes. Along the way there may be several revisions on how to implement the decoding intelligently, and I think going and doing the refactoring first might end up being more work, not to mention possibly breaking something in one of the revisions, since that would be done on 'active' code in ImportFFMpeg.cpp. So I propose that I do the following steps: 1.Get the basic class designs in with stub functions. 2.Implement the basic linear background thread loading feature 3.Implement the seeking feature and related error handling 4.Handleunforseen details and tests concerning multithreaded ffmpeg. 5.Refactor the code from ImportFFMpeg.cpp/with feedback If all of these steps were to go smoothly and quickly, then I could refactor before my first commit. While that is possible, it is unlikely. I'd feel much more comfortable checking in each of those steps instead at no risk to the codebase. I could use a local commit mechanism such as git, but I'd prefer to use the google svn. I'm talking about commiting one class (ODDecodeFFMPEGTask.h/cpp) and mainly modifying another that will only have one or two ifdef EXPERIMENTALs in one file (ImportFFMpeg.cpp) so that it will not change the runtime behavior. Also, another reason that I have to concede is that it's a lot more fun and encouraging to see the prototype work first. Michael > --James. > > > > > > > On 08/03/2010 16:09, Michael Chinen wrote: > >> I've been working with ffmpeg and libmad in my own projects, so I feel >> now is a good time to put in on-demand versions into Audacity under >> experimental (just as it is flac on-demand.) In theory this will not >> destabilize audacity - there will be no changes for example, to >> ImportFFMPEG.cpp with the EXPERIMENTAL_ODFFMPEG flag off, and with >> them on, only a few changes will be made (see ImportFlac.cpp for an >> example.) >> >> Ideally, for optimal code reuse, I will need to refactor some of the >> code in ImportFFMPEG.cpp to seperate the parts that don't touch >> audacity UI (e.g. the progress bar.) But for the risk of >> destabilization I will not do this till after we release 1.4/2.0, and >> just use well marked copy/paste snippets for now in OD cpp files. >> >> There is feature freeze on, and this will be respected by not changing >> the runtime behavior of audacity in any way. I wish to do this now >> because motivation is high. Furthermore, I just went through the OD >> code review as well and want to do it while both it and these >> libraries are still fresh in my head. I do not anticipate strain from >> other developers, except that it would be nice if they could at the >> new files to the other platform projects. Any objections? >> >> Michael >> > > > |
From: James C. <cr...@in...> - 2010-03-09 13:22:16
|
On 09/03/2010 02:10, Michael Chinen wrote: > The main point is that I don't know how much of the code from > ImportFFMpeg will be reusable at design time, and that I'd like to be > able to commit the prototype in the period it takes up to that point. > I think it is worthwhile to create a working prototype using some > well-marked copy/pasting/editing before making the refactoring > changes, then finalize and decide exactly how and where to make the > refactoring cuts into the ImportFFMpeg classes. Along the way there > may be several revisions on how to implement the decoding > intelligently, and I think going and doing the refactoring first might > end up being more work, not to mention possibly breaking something in > one of the revisions, since that would be done on 'active' code in > ImportFFMpeg.cpp. > > So I propose that I do the following steps: > 1.Get the basic class designs in with stub functions. > 2.Implement the basic linear background thread loading feature > 3.Implement the seeking feature and related error handling > 4.Handleunforseen details and tests concerning multithreaded ffmpeg. > 5.Refactor the code from ImportFFMpeg.cpp/with feedback OK. Understood. That's fine. As long as you do include step 5. > Also, another reason that I have to concede is that it's a lot more > fun and encouraging to see the prototype work first. > Yes. I was afraid of that :-) In our quest for stability we have at times lost sight of the fact that Audacity has to be fun. If Audacity is unstable all bets are off - so it needs to be pretty darned reliable to have a good name, to be used and liked by people. But if we have that, and if we can extend safely without destabilising then a whole load more is possible. If anyone else is getting angsty about the apparent slow progress of Audacity, please talk to me off list. --James. |