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

[Reimar Döffinger]

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:
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).
Also you have the endianness problem, if the CPU endianness
changes the DSP endianness wouldn't necessarily I guess...