On Wed, Jan 06, 2016 at 02:53:32PM -0300, James Almer wrote:
> On 1/6/2016 2:32 PM, foo86 wrote:
> > OK, I'll start changing the patch.
> > 
> > Some questions so far:
> > 
> > 1. Should I remove old decoder files in separate commit first or should
> > I simply proceed with replacing entire content of certain files (e.g.,
> > dcadec.c, dca_exss.c, dca_xll.c)?
> 
> Yeah, send it as separate patches to make reviewing easier. Whoever commits it
> can then squash it into a single patch (Like it was done in commit b08569a2) 
> if
> necessary.
> 
> Also, while at it, try to split the main header into separate headers for some
> of the modules (xll, exss, dsp which already exists for the old decoder, etc).

OK.

> > 2. Is it OK to leave arch-specific dca code as well as dcadsp.c
> > untouched for now? I'd really like to postpone dealing with that until
> > I'm done with generic code, especially since the new decoder is not
> > slower already. This means some assembly functions (ff_dca_lfe_fir32_*,
> > ff_dca_qmf_32_subbands_*) will still be compiled in but unused.
> > libavcodec/dcadsp.c will be still around but not compiled.
> 
> Try to disable or remove code that will not be used. Git will easily let you
> recover any of it in the future if needed.
> Better than keeping dead code in the tree, IMO, but do what you think will 
> make
> your work easier.

Yeah, I'll probably remove it for now and recover any needed parts
later.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Reply via email to