On Wed, May 25, 2016 at 04:31:10PM -0300, James Almer wrote: > On 5/25/2016 3:35 PM, foo86 wrote: > > On Wed, May 25, 2016 at 11:34:13AM -0300, James Almer wrote: > >> On 5/23/2016 11:58 AM, foo86 wrote: > >>> --- > >>> Updated version of the patch: don't set avctx field in DCAExssParser > >>> structure > >>> to indicate that ff_dca_exss_parse() is being called from parser context. > >>> > >>> libavcodec/dca_parser.c | 68 > >>> ++++++++++++++++++++++++++++++++++++++++++++++--- > >>> 1 file changed, 65 insertions(+), 3 deletions(-) > >>> > >> > >> Added the new dependencies on dca_exss.o and dcadata.o to dca_parser and > >> applied. Thanks! > > > > Oh, I missed parser dependencies. Thanks for fixing that. > > > > Would it be better to move ff_dca_sampling_freqs/freq_ranges arrays to > > dca.c so that parser dependency on dcadata.o can be avoided? I can send > > a patch for that. dcadata is huge and someone may want to build the > > demuxer/parser, but not the decoder. > > Alternatively you could move it to dcadata.h and make it static const.
Won't this bloat the resulting binary by including multiple copies of array from different object files? > But yeah, moving them outside of dcadata.c is a good idea in any case. > The above could also be done for avpriv_dca_sample_rates, but for this > one the symbol will have to be scheduled for removal with the next major > bump since, even if it's not public, it's still exported. > Wrapping it with a LIBAVCODEC_VERSION_MAJOR preprocessor check should > suffice. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
