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

Måns Rullgård mans
Tue Sep 7 21:38:03 CEST 2010


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:
>>> On Tue, Sep 7, 2010 at 5:45 AM, Ronald S. Bultje <rsbultje at gmail.com> wrote:
>>> > On Sun, Sep 5, 2010 at 6:15 PM, Felipe Contreras
>>> > <felipe.contreras at gmail.com> wrote:
>>> >> +struct mp4vdec_args {
>>> >> + ? ? ? uint32_t size;
>>> >> + ? ? ? uint16_t num_streams;
>>> >> +
>>> >> + ? ? ? uint16_t in_id;
>>> >> + ? ? ? uint16_t in_type;
>>> >> + ? ? ? uint16_t in_count;
>>> >> +
>>> >> + ? ? ? uint16_t out_id;
>>> >> + ? ? ? uint16_t out_type;
>>> >> + ? ? ? uint16_t out_count;
>>> >> +
>>> >> + ? ? ? uint16_t reserved;
>>> >> +
>>> >> + ? ? ? uint32_t max_width;
>>> >> + ? ? ? uint32_t max_height;
>>> >> + ? ? ? uint32_t color_format;
>>> >> + ? ? ? uint32_t max_framerate;
>>> >> + ? ? ? uint32_t max_bitrate;
>>> >> + ? ? ? uint32_t endianness;
>>> >> + ? ? ? uint32_t profile;
>>> >> + ? ? ? int32_t max_level;
>>> >> + ? ? ? uint32_t mode;
>>> >> + ? ? ? int32_t preroll;
>>> >> + ? ? ? uint32_t display_width;
>>> >> +};
>>> >
>>> > What are all these?
>>>
>>> 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.

>> 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.

>> 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.

-- 
M?ns Rullg?rd
mans at mansr.com



More information about the ffmpeg-devel mailing list