[FFmpeg-devel] [PATCH][VAAPI][6/6] Add H.264 bitstream decoding (take 16)

[Michael Niedermayer]

On Thu, Jun 04, 2009 at 02:57:54PM +0200, Cyril Russo wrote:
> Michael Niedermayer a ?crit :
[...]

>>
>>   
>>> +static void fill_reference_pic_list(VAPictureH264 RefPicList[32],     
>> [...
>>   
>>> +static void h264_fill_plain_pred_weight_table(H264Context *h, int list,
>>>     
>> [...]
>>   
>>> +
>>> +/** Initialize and start decoding a frame with VAAPI. */
>>> +static int vaapi_h264_start_frame(AVCodecContext *          avctx,     
>>
>> i must say the prefixes still are entirely random
>> vaapi_h264_ here h264_ above and nothing above that
>> it all would be fine where there a difference but its all h264 and vaapi
>> related code.
>>   
>
> Ok, here's the idea I've understood from other files, let me know if I'm 
> wrong.
> - vaapi_codecname_[...] are the exported functions (ex: 
> vaapi_vc1_start_frame, vaapi_h263_start_frame, vaapi_h264_start_frame...)

they are not really exported, they are static, pointers to them are
exported


> - other prefix have been removed, and I've renamed the functions to prefix 
> vaapi on the structure that's modified instead
> (ex: init_picture => init_vaapi_pic, fill_reference_pic_list => 
> fill_vaapi_reference_pic_list, fill_vaapi_pic => kept the same...)
>
> I think it more obvious this way.

yes, i think so too


[...9
> +/** This file implements the glue code between FFmpeg's and VAAPI's structures. */

this needs some doxy tag to apply to the file i think


> +
> +/** Reconstruct bitstream slice_type. */
> +static int get_slice_type(H264Context *h)
> +{
> +    switch (h->slice_type) {
> +    case FF_P_TYPE:  return 0;
> +    case FF_B_TYPE:  return 1;
> +    case FF_I_TYPE:  return 2;
> +    case FF_SP_TYPE: return 3;
> +    case FF_SI_TYPE: return 4;
> +    default:         return -1;
> +    }
> +}
> +

> +/** Initialize an empty VAAPI picture.
> + *  VAAPI requires a fixed size reference picture array. */

*/ should be on a line of its own


[...]

> +/** Decoded picture buffer. */
> +typedef struct DPB {
> +    unsigned int   size;
> +    unsigned int   max_size;
> +    VAPictureH264 *pics;
> +} DPB;
> +

> +/** Append Picture into the decoded picture buffer, in a VAAPI form that 

append and into sound odd together


> + *  merges the second field picture attributes with the first, if available.
> + *  The decoded picture buffer's size must be large enough 
> + *  to receive the new VAAPI picture object. */
> +static int append_vaapi_dpb(DPB *dpb, Picture *ff_pic)

the name is not ideal


[...]
> +/** Fill VAAPI's reference frames array. */
[...]

> +/** Fill VAAPI reference picture lists.

what is the difference between the 2 ?


> + *  @param[out] RefPicList  VAAPI internal reference picture list
> + *  @param[in]  ref_list    A pointer to the FFmpeg reference list
> + *  @param[in]  ref_count   The number of reference pictures in ref_list
> + */    
> +static void fill_vaapi_reference_pic_list(VAPictureH264 RefPicList[32], 
> +                                          Picture *     ref_list, 
> +                                          unsigned int  ref_count)
> +{
> +    unsigned int i, n = 0;
> +    for (i = 0; i < ref_count; i++)
> +        if (ref_list[i].reference)
> +            fill_vaapi_pic(&RefPicList[n++], &ref_list[i], 0);
> +
> +    for (; n < 32; n++)
> +        init_vaapi_pic(&RefPicList[n]);
> +}
[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Frequently ignored awnser#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090604/ad626b01/attachment.pgp>