[Ffmpeg-devel] [bug] raw.c link failure on ff_ac3_parse_header
Thu Apr 12 11:46:09 CEST 2007
Michael Niedermayer wrote:
> On Thu, Apr 12, 2007 at 12:58:42AM +0200, Diego Biurrun wrote:
>> On Wed, Apr 11, 2007 at 01:10:06PM +0200, Michael Niedermayer wrote:
>>> On Wed, Apr 11, 2007 at 11:22:51AM +0200, Diego Biurrun wrote:
>>>> On Tue, Apr 10, 2007 at 09:53:18AM +0100, M?ns Rullg?rd wrote:
>>>>> Diego Biurrun <diego at biurrun.de> writes:
>>>>>> I'm thinking that it might be cleaner to move ff_ac3_parse_header out of
>>>>>> ac3.c and into parser.c where the other parse functions are. This would
>>>>>> save some #ifdefs in ac3.c.
>>>>> I'm undecided on the location of these things. In a way I like to
>>>>> keep everything relating to a particular codec together, especially
>>>>> when the decoder uses the same functions. OTOH keeping the parser
>>>>> code in one place has its virtues.
>>>> Here's an alternative patch that moves the code. It's slightly more
>>>> intrusive since it has to move code around, but it adds only one #ifdef.
>>>> I think I prefer this version.
>>> iam against moving ac3 related code from ac3 related files to parser.c
>> But parser.c already contains code related to several other codecs like
>> MPEG-4 and AAC, MP2, MP3, AC3. The rest of the AC3 parsing code is
>> there. Also, without even more #ifdefs, when you need just this one
>> function, you have to link all of ac3.o into libavcodec.
>> The first patch adds 4 #ifdef conditionals, the second just one and to a
>> file that already has quite a few. My vote goes to this variant.
> my vote goes to putting all the parsing code in <codec>_parser.c
my vote is: put code in parser.c until <codec>_parser.c is in effect,
or implement a generic avformat demuxer for raw based on codec specified
and AVParser activation.
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
SMARTJOG S.A. http://www.smartjog.com
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312
More information about the ffmpeg-devel