Re: [Audacity-devel] Feature freeze and ffmpeg on-demand

[James C. <cr...@in...>]

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.