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

[Cyril Russo]

Michael Niedermayer a ?crit :
> 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
>   

Sure, I know this. But, as I don't want to modify the other vaapi files
(at least, not in that patch), I think it's better to be consistent with
the other code.
In the other files, the names are build following the pattern
vaapi_##CODEC##_##function

There are 3 of them in each files, by the end of the file, so they can
be located quite easily.
Unless you expressely say to rename them, I'd prefer to keep them that way.

I've completed the initial comment to state so.

>
>> +/** Fill VAAPI's reference frames array. */
>>     
> [...]
>
>   
>> +/** Fill VAAPI reference picture lists.
>>     
>
> what is the difference between the 2 ?
>
>
>   
The picture isn't the frame (...you know this..., so I guess the real
question was "Why is there a difference between the 2?")

Generally speaking, the reference frame for VAAPI is linked to a
hardware buffer by an index.
As specified elsewhere in the file, VAAPI doesn't infer any value, so it
must have access to all the data for its operations (even defaults)

The former takes a FFmpeg's H264 context, and for each picture with a
(nonzero) reference, create a reference frame entry in the VAAPI ref's
array.
It is only used in the start_frame function once.
It's not an initialization function for the given argument, as it only
deal with the reference frame array of the argument.
It's used to keep track of frames that the decoding process need to
refer too later on, and more specifically, when using interlaced content
(as VAAPI require merged top and bottom field IIUC).


The latter is called in the decode_slice function. It minimally fills
the reference picture list for the current slice (as most of the work
was done in the former),
and only for the actual reference pictures (of the slice).
It acts on another list of reference than the former, as it deals with
VAAPI's slice reference list.

So I guess the process is more like:
1) When starting a frame, prepare the reference frames, and if
interlaced content, merge the reference indexes.
2) When decoding a slice, use the slice's reference picture if present
and fill the reference list for the slice.
3) Enqueue the slice to decoding context in hardware
4) Keep the hardware buffer if it's referred.


In the attached patch, I've renamed the former function to
prepare_vaapi_reference_frame_array, as it only fill the frame's ref
array with per-frame flags.
I've added a comment, so it's more clear too.


Disclaimer:
I haven't dug into VA internals & implementation, so I don't know WHY it
needs to merge the reference list for interlaced content (probably a
hardware limit?).
However, the VA header states (from
http://freedesktop.org/wiki/Software/vaapi ) :

/* H.264 Picture Parameter Buffer */
/*
  * For each picture, and before any slice data, a single
  * picture parameter buffer must be send.
  */
typedef struct _VAPictureParameterBufferH264
{
     VAPictureH264 CurrPic;
     VAPictureH264 ReferenceFrames[16];  /* in DPB */
[...]


I haven't written this code (Gwenole has), I'm only trying to use it and
thought it was a shame that only H264 missed in the trunk.
I think Gwenole did it right (we must send a reference list before the
first frame).
It's working in this current state on my platform.

If you absolutely want to know why VA merge the ref list, please ask
Gwenole directly.

Cheers,
Cyril







-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ffmpeg.hwaccel.vaapi.h264.17.patch
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090608/ea1548f8/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Portion de message jointe
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090608/ea1548f8/attachment.asc>