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

[Cyril Russo]

>> I disagree here:
>>
>> ITU H264 states (p101):
>>
>> 7.4.3 Slice header semantics
>> When present, the value of the slice header syntax elements 
>> pic_parameter_set_id, frame_num, field_pic_flag,
>> bottom_field_flag, idr_pic_id, pic_order_cnt_lsb, 
>> delta_pic_order_cnt_bottom, delta_pic_order_cnt[ 0 ],
>> delta_pic_order_cnt[ 1 ], sp_for_switch_flag, and slice_group_change_cycle
>> *shall* be the same in all slice headers of a coded picture.
>>
>>
>> The function only want to know if the next slices will be top or bottom 
>> field (infered from from H264's bottom_field_flag), and if it's a 
>> short/long term reference (inferred from H264's frame_num).
>> It also extract the top/bottom field order count (inferred from H264 
>> delta_pic_order_cnt[0] and [1])
>> Don't be mislead by the fill_vaapi_pic function that is (re)used to really 
>> fill an *entire* VAAPI pic later in decode_slice.
>>     
>
> prepare_vaapi_reference_frame_array() uses list_count and ref_count, these
> are per slice not per frame values while the function is called per frame
> your explanation does not seem to explain this discrepancy ...
>
> [...]
>   
If I understand H264.c code correctly,
decode_frame (7677) calls:
decode_nal_units (7459) that calls:
decode_slice_header (3704) that *fills* the ref_count and list_count 
(around line 3980), just before calling hwaccel->start_frame.

I think the H264 code is correct here (wrt the standard) (in that it 
only decodes slice *header*).
HWAccel::start_frame is called after the first slice is parsed (it isn't 
wrong by itself, I can't figure how it could be differently).
After this case, HWAccel::decode_slice is called for each other slice.

Then, either we interpret the VAAPI doc strictly as it's written:

"For each picture, and before any slice data, a single picture parameter buffer must be send."

In that case, it only needs one of those VAPictureH264 (with the ref 
only for the first slice) in the start_frame.

Either we intepret the VAAPI doc as what you're suggesting, where each 
slice accumulate in the ref array that is send first (in that case, I 
need to merge the ref in decode_slice function).
I think the former is the intended case, even if, I agree, it isn't a 
very smart choice.

I *guess* removing that ref array on start_frame would work for my 
particular hardware decoder, but I think it's better to stick to the 
VAAPI std.

I've corrected all you've asked previously in the attached patch.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ffmpeg.hwaccel.vaapi.h264.19.patch
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090610/dc81df67/attachment.asc>