[FFmpeg-devel] [PATCH v2 2/2] avcodec/dca_parser: set duration for core-less streams
jamrial at gmail.com
Thu May 26 01:18:28 CEST 2016
On 5/25/2016 7:51 PM, foo86 wrote:
> 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?
The compiler should optimize it away on any file that includes the header
but doesn't use the tables. But now that i check both of these are used by
almost every dca decoder object and not just a couple, so yeah, it would
probably be pointless duplication.
Move them to dca.c in that case.
>> 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
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
More information about the ffmpeg-devel