[FFmpeg-devel] [PATCH 2/3 v1.1] avcodec/vaapi: add fields for VAAPI VC-1 interlaced decoding

Jerome Borsboom jerome.borsboom at carpalis.nl
Wed Feb 28 10:48:44 EET 2018


> On 25/02/18 19:12, Jerome Borsboom wrote:
>> avcodec/vaapi: add fields for VAAPI VC-1 interlaced decoding
>> 
>> Pass necessary bitstream elements to the VAAPI VC-1 decoder in order
>> to start doing interlaced decoding in hardware.
>> 
>> Signed-off-by: Jerome Borsboom <jerome.borsboom at carpalis.nl>
>> ---
>>  libavcodec/vaapi_vc1.c | 167 ++++++++++++++++++++++++++++++++++++++++---------
>>  1 file changed, 138 insertions(+), 29 deletions(-)
>> 
>> diff --git a/libavcodec/vaapi_vc1.c b/libavcodec/vaapi_vc1.c
>> index 525376790e..a137979dd4 100644
>> --- a/libavcodec/vaapi_vc1.c
>> +++ b/libavcodec/vaapi_vc1.c
>> @@ -44,7 +44,8 @@ static inline int vc1_has_MVTYPEMB_bitplane(const VC1Context *v)

<lines removed>

>>  
>> +#if VA_CHECK_VERSION(1, 1, 0)
> 
> IMO it would be preferable not to guard this function with the libva version check - it doesn't depend on anything about libva (it's only the use of it that does), so it would be better if it's always built and the compiler can eliminate it later.
> 
> (Mark them with av_unused to avoid the warning.)
> 

OK. Will change and resubmit.

>> +static inline int vc1_get_INTCOMPFIELD(const VC1Context *v)
>> +{
>> +    if ((v->s.pict_type == AV_PICTURE_TYPE_P && !v->p_frame_skipped) &&
>> +        v->fcm == ILACE_FIELD &&
>> +        v->mv_mode == MV_PMODE_INTENSITY_COMP)
>> +        switch (v->intcompfield) {
>> +        case 1: return 1;
>> +        case 2: return 2;
>> +        case 3: return 0;
>> +        }
>> +    return 0;
>> +}
>> +#endif
>> +

<lines removed>>

> Is this expected to pass the two fate tests for VC-1 interlaced, fate-vc1_sa10143 and fate-vc1_ilaced_twomv?  (It doesn't on my system, all output frames are different.)  If not, could you explain why not?
> 
> Thanks,
> 
> - Mark

I have a feeling that the software decoder in FFmpeg is not fully 
compliant with the VC-1 spec. The loopfilter, as currently implemented, 
may be wrong for interlaced content. I am still investigating this issue.

As far as I can see, there are no visual differences between the output 
of the software decoded and the hardware decoded images.


Regards,
Jerome


More information about the ffmpeg-devel mailing list