[FFmpeg-devel] [PATCH][7/8] Add VA API accelerated H.264 decoding (take 3)

[Gwenolé Beauchesne]

Hi,

Le 5 f?vr. 09 ? 19:51, Stephen Warren a ?crit :

>> @@ -7502,7 +7524,11 @@ static int decode_nal_units(H264Context *h,  
>> const uint8_t *buf, int buf_size){
>>             av_log(avctx, AV_LOG_DEBUG, "Unknown NAL code: %d (%d  
>> bits)\n", h->nal_unit_type, bit_length);
>>         }
>>
>> -        if(context_count == h->max_contexts) {
>> +        if(IS_VAAPI_ENABLED(s)) {
>> +            /* Make sure we never call execute_decode_slices() */
>> +            context_count = 0;
>> +        }
>> +        else if(context_count == h->max_contexts) {
>>             execute_decode_slices(h, context_count);
>>             context_count = 0;
>>         }
>
> The VDPAU code handles this by making execute_decode_slices return  
> immediately
> if VDPAU is enabled. VDPAU and VA API should really be consistent. I  
> think we
> copied the VDPAU mechanism from existing MPEG-2 XvMC integration.

Well, I don't like things getting incremented for no reason/use, so I  
prefer making sure they never grow instead. ;-) But you are also right  
to exit early in that function.

> Note however, that there's a reason that *some* of the information  
> VDPAU uses
> is picked up during frame_end time not frame_start time. My memory  
> is poor,
> but I *think* the call to execute_ref_pic_marking() right before the  
> existing
> ff_vdpau_h264_picture_complete() modifies one of the data fields  
> VDPAU uses,
> and I *think* that was h->frame_num (everything else comes from SPS/ 
> PPS
> anyway, so shouldn't be modified after parsing those). It looks like  
> VA API
> grabs this during ff_vaapi_h264_frame_start() rather than
> ff_vaapi_h264_frame_end(), which I suspect is a bug.

Now that you mention it, it's possible. The remaining issue I have is  
some frames are not displayed in the right order for very specific  
streams. The pictures don't have any artifacts (like in the past  
because of bad ReferenceFrames[] construction), they just aren't  
displayed in the right order. That's with VA API on Intel. With VDPAU  
(your original work r34something, or my wrapper), those streams don't  
play at all. MPlayer aborts with an error 25 (or whatever is the  
generic error code and that I don't remember), I need to investigate  
further.

On the other hand, isn't frame_num the verbatim copy from the  
bitstream? Isn't Picture::pic_id the thing that is modified during  
ref_pic_marking instead? i.e. what you called frame_idx, though it's  
not the exact same semantics, I think.

I think I placed ff_vaapi_h264_frame_start() at the right location:  
after everything is parsed and before actual decoding of the first  
slice. It's also at this location that what-FFmpeg-uses-as-a-DPB  
should valid for proper decoding.

BTW, the latest incarnation of mplayer-vaapi and vdpau-video work  
equivalently to mplayer-vdpau. According to my poor eyes, of course.  
The non smooth motion you might see is my failure to implement double  
buffering correctly, I think.

Regards,
Gwenole.