[FFmpeg-devel] [RFC/PATCH 6/8] tidsp: add mp4v configuration

[Felipe Contreras]

2010/9/8 M?ns Rullg?rd <mans at mansr.com>:
> Felipe Contreras <felipe.contreras at gmail.com> writes:
>> On Wed, Sep 8, 2010 at 8:16 AM, Reimar D?ffinger
>> <Reimar.Doeffinger at gmx.de> wrote:
>>> On Wed, Sep 08, 2010 at 01:58:14AM +0300, Felipe Contreras wrote:
>>>> Right, although I've never encountered a problem with that. All the
>>>> code I've seen assumes the endianness is determined at compilation
>>>> time.
>>>
>>> That isn't the problem, the question is will the DSP code still
>>> work if the endianness is the other one? The struct will still look
>>> different in memory if the endianness is changed, compile-
>>> vs. runtime does not matter. ?It's not impossible that the DSP
>>> guesses the endianness on its own, it would be unusual though.
>>
>> Yes, that is true, and as I said, if somebody can provide some
>> pointers how to do that properly I will consider it.
>
> You are the self-proclaimed expert here. ?Why don't you apply some of
> that expertise?

I never proclaimed myself an expert on anything.

I do have experience in getting these codecs working properly, and I
do understand how tidspbridge works, along with some knowledge of
linux memory managment, OMAP 3 MMU's, and ARM cache coherence; just
enough to make them work in an optimized way.

I do not have experience in esoteric ARM features.

>> However, at the end of the day is libschroedinger has has a similar
>> flaw, all you can do is say yes, or no, to use it.
>
> I fail to see the relevance of libschroedinger. ?Aside, what options
> other than yes or no could there possibly be? ?Use half of it?

That is precisely my point; once I split the code into libtidsp-ng;
those are your options.

-- 
Felipe Contreras