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

[Felipe Contreras]

2010/9/7 M?ns Rullg?rd <mans at mansr.com>:
> Felipe Contreras <felipe.contreras at gmail.com> writes:
>> On Tue, Sep 7, 2010 at 10:15 PM, Reimar D?ffinger
>> <Reimar.Doeffinger at gmx.de> wrote:
>>> On Tue, Sep 07, 2010 at 12:44:12PM +0300, Felipe Contreras wrote:
>>>> These are arguments needed to start the DSP algorithm.
>>>
>>> Assuming you mean they are directly pass to hardware:
>
> It is probably processed by software running on the DSP. ?The hardware
> accelerators operate at a lower level.

Indeed.

>>> I don't think a struct is a good way to do this,
>>> you're relying on the compiler not inserting some
>>> padding just because it likes to (e.g. on a machine
>>> that can only do 32 bit read and writes it might allocate
>>> 4 bytes for all the uint16_t - I admit I haven't double-
>>> checked this is indeed allowed).
>>
>> You mean padding at the end, or in the middle? Appending stuff at the
>> end is generally not a problem (although some algos check the size
>> specified). If it's in the middle... how do you suggest fixing that?
>
> The machine ABI specifies struct layout, and I don't think TI DSPs
> ever come with anything other than an ARM MCU, so it should be safe
> for this.

Cool.

>>> Also you have the endianness problem, if the CPU endianness
>>> changes the DSP endianness wouldn't necessarily I guess...
>>
>> That is true... although on OMAP 3 I don't think that's a likely scenario.
>
> The ARM core will happily run in big endian data mode, quite
> independently from the DSP. ?It is even a per-process flag which can
> be changed at any time.

Right, although I've never encountered a problem with that. All the
code I've seen assumes the endianness is determined at compilation
time.

If you have a suggestion how to check that and transform the data
efficiently I would consider it for libtidsp-ng, but I thought it was
kind of implied that this code wouldn't belong to FFmpeg.

-- 
Felipe Contreras