> Hi, > > Sorry, I cannot test until next week. Does it actually work now? Based > on some #ffmpeg-devel backlogs :)
Yes, it works flawlessly, except for samples using ScalingLists. See http://fate-suite.ffmpeg.org/hevc-conformance/ the SLIST_* files. Those files decode with strong artifacts, with both gstreamer and ffmpeg showing the exact same ones. Comparing the trace logs from gst and ffmpeg, they do set the ScalingLists somewhat diffrently. The values ffmpeg sets work fine for vdpau and dxva, so I suspect that the issue here might be at a lower layer. >> +hevc_vaapi_hwaccel_deps="vaapi VAPictureParameterBufferHEVC" >> +hevc_vaapi_hwaccel_select="hevc_decoder" >> hevc_vdpau_hwaccel_deps="vdpau VdpPictureInfoHEVC" >> hevc_vdpau_hwaccel_select="hevc_decoder" >> mpeg_vdpau_decoder_deps="vdpau" >> @@ -5146,6 +5148,8 @@ check_type "windows.h dxva.h" "DXVA_PicParams_HEVC" >> -DWINAPI_FAMILY=WINAPI_FAMIL >> check_type "windows.h d3d11.h" "ID3D11VideoDecoder" >> check_type "d3d9.h dxva2api.h" DXVA2_ConfigPictureDecode >> -D_WIN32_WINNT=0x0602 >> >> +check_type "va/va.h" "VAPictureParameterBufferHEVC" >> + >> check_type "vdpau/vdpau.h" "VdpPictureInfoHEVC" >> >> if ! disabled w32threads && ! enabled pthreads; then > > Does this mean vaapi support will be disabled now if the user doesn't > have the very latest libva headers and libs? Looks reasonable though, > based on existing practice. So, should be ok. No, the check_type only enables or disables VAPictureParameterBufferHEVC based on if the type is found, which is then used as dependency for hevc_vaapi_hwaccel. >> + if (h->nal_unit_type >= NAL_BLA_W_LP && h->nal_unit_type <= >> NAL_CRA_NUT) { >> + pp->slice_parsing_fields.bits.RapPicFlag = 1; >> + } else { >> + pp->slice_parsing_fields.bits.RapPicFlag = 0; >> + } > > If IS_IRAP(h) is not suitable (22 & 23 NAL unit types needed?), > couldn't we have some convenient macro that could be helpful to other > hwaccels too? va_dec_hevc.h describes this flag as "current picture with NUT between 16 and 21 inclusive", which is not something I found an existing macro for, and no other hwaccel seems to look for this. >> + if (IS_IDR(h)) { >> + pp->slice_parsing_fields.bits.IdrPicFlag = 1; >> + } else { >> + pp->slice_parsing_fields.bits.IdrPicFlag = 0; >> + } > > IdrPicFlag = IS_IDR(h); ? > >> + if (IS_IRAP(h)) { >> + pp->slice_parsing_fields.bits.IntraPicFlag = 1; >> + } else { >> + pp->slice_parsing_fields.bits.IntraPicFlag = 0; >> + } > > IntraPicFlag = IS_IRAP(h); ? I wasn't sure if setting the result of those macros, which are a logical expression, is guaranteed to be 0 or 1, and how that interacts with bit fields in a struct, so I made sure it's 0 or 1. >> + /* TODO */ >> + pp->pic_fields.bits.NoPicReorderingFlag = 0; >> + pp->pic_fields.bits.NoBiPredFlag = 0; >> + pp->st_rps_bits = 0; >> +} > > Could this be done? :) Or this first round is good enough for now? st_rps_bits is implemented in the current version, not sure about the other two.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel