[FFmpeg-cvslog] r17345 - trunk/libavcodec/xvmc.h

[Ivan Kalvachev]

On 2/15/09, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Sun, Feb 15, 2009 at 09:13:00PM +0100, iive wrote:
>> Author: iive
>> Date: Sun Feb 15 21:13:00 2009
>> New Revision: 17345
>>
>> Log:
>> Describe all fields in xvmc struct.
>
> [...]
>> +    /** Pointer to the block array allocated by XvMCCreateBlocks()
>> +        it contins differential pixel data (in MoCo mode)
>> +        or coefficients for IDCT.
>> +        - application - set during initialization
>> +        - libavcodec  - unchanged
>> +    */
>>      short*          data_blocks;
>
> there are 2 things here
> the pointer and the data it points to
> why is it not allocated by lavc?

Because it is allocated by special xvmc function.

1. Allocating it by libavcodec means it should link to xvmc library.

2. In theory the xvmc library can allocate it into agp memory and dma
it directly
from that location. For that reason I keep the possibility to don't
overwrite data/mv blocks after each draw_band.
Of course xvmc doesn't do that (coz it sux) for any hardware I know.

>> +    /** Pointer to the macroblock description array allocated by
>> XvMCCreateMacroBlocks().
>> +        - application - set during initialization
>> +        - libavcodec  - unchanged
>> +    */
>>      XvMCMacroBlock* mv_blocks;
>
> same

ditto
With that difference that it is highly unlikely the hardware
format to be the same as the xvmc one.

>> +
>> +    /** Number of all MB descriptions that could be stored in the
>> mv_blocks array.
>> +        - application - set during initialization
>> +        - libavcodec  - unchanged
>> +    */
>>      int             total_number_of_mv_blocks;
>
> allocated_num_of_mv_blocks seems a better name
>
>
>> +
>> +    /** Number of all blocks that could be stored at once in the
>> data_blocks array.
>> +        - application - set during initialization
>> +        - libavcodec  - unchanged
>> +    */
>>      int             total_number_of_data_blocks;
>
> same
>
>
>> -    int             idct;                         ///< indicate that IDCT
>> acceleration level is used
>> -    int             unsigned_intra;               ///< +-128 for intra
>> pictures after clipping
>> -    XvMCSurface*    p_surface;                    ///< pointer to
>> rendered surface, never changed
>> +
>> +    /** Indicates that the hardware would interpret data_blocks as IDCT
>> cefficients
>> +        and perform IDCT on them.
>> +        - application - set during initialization
>> +        - libavcodec  - unchanged
>> +    */
>> +    int             idct;
>
> if this is set by the app, why are there 2 PIX_FMT_XVMC_MPEG2 ?

Because the pix_fmt are passed to the application and it chooses
whenever to pick surface with and without it.

Hum, I feel what you want to say.

> [...]
>> +    /** top/bottom field or frame
>> +        - application - unchanged
>> +        - libavcodec  - set
>> +    */
>> +    unsigned int    picture_structure;
>
> this should possibly rather be in AVFrame

I can't remember if draw_band() used AVFrame when I wrote it.
I guess you are right.

>> +
>> +    /**XVMC_SECOND_FIELD - 1st or 2nd field in the sequence
>> +        - application - unchanged
>> +        - libavcodec  - set
>> +    */
>> +    unsigned int    flags;
>
> picture_structure & top_field_first is not enough?

It's the opposite of s->first_field .

> anyway this is pretty good alraedy
> so +6 (from the remainig 8 for user vs. lavc clarifications)

What is left?

> diego 16
> ivan 19.5
>
> PS: its time you break compile again ;)

How, If I say I won't be committing code until Diego catches up
you are probably going to find something to penalize me and
force me to catch up.

>From Monday I won't be having so much free time.
I may even let Diego win.