The patch is Reviewed-by: Nayan Deshmukh <nayan26deshm...@gmail.com>
On Mon, Jan 23, 2017 at 7:01 PM, Christian König <deathsim...@vodafone.de> wrote: > Ah, yes of course. If we delay creating the decoder we need to call > begin_frame() again as well. > > Please review and/or test the attached patch. Andy I did understand you > right that this is already a Tested-by from your side, isn't it? > >> I am wondering if calling decode_bitstream one at a time for each >> buffer is similar to >> calling it with all buffers at once? > > Yes, that is correct. It's just not as efficient. > > One problem with VA-API is that it doesn't seem to guarantee that buffers > stays around after handing them of to the decoder (the ownership handling of > buffers and surfaces is a totally mess). > > So we would need to make a copy of the buffer content to submit it again all > at once. > > Regards, > Christian. > > > Am 21.01.2017 um 20:46 schrieb Andy Furniss: >> >> Nayan Deshmukh wrote: >>> >>> Hi Christian, >>> >>> The new patch leads to seg fault on my system. You forgot to set the >>> needs_begin_frame to true when the decoder is created. Here's diff for >>> reference: >> >> >> Setting true there seems to fix, though only a quick test. >> >> The patch below sets false :-) >> >>> -------------------------------- >>> diff --git a/src/gallium/state_trackers/va/picture.c >>> b/src/gallium/state_trackers/va/picture.c >>> index e75006d..a51e482 100644 >>> --- a/src/gallium/state_trackers/va/picture.c >>> +++ b/src/gallium/state_trackers/va/picture.c >>> @@ -178,6 +178,8 @@ handlePictureParameterBuffer(vlVaDriver *drv, >>> vlVaContext *context, vlVaBuffer * >>> >>> if (!context->decoder) >>> return VA_STATUS_ERROR_ALLOCATION_FAILED; >>> + >>> + context->needs_begin_frame = false; >>> } >>> >>> return vaStatus; >>> ---------------------------------- >>> >>> I am wondering if calling decode_bitstream one at a time for each >>> buffer is similar to >>> calling it with all buffers at once? >>> >>> Cheers, >>> Nayan >>> >>> On Thu, Jan 19, 2017 at 8:36 PM, Andy Furniss <adf.li...@gmail.com> >>> wrote: >>>> >>>> Andy Furniss wrote: >>>>> >>>>> >>>>> Christian König wrote: >>>>>> >>>>>> >>>>>> Hi Andy, >>>>>> >>>>>> Am 19.01.2017 um 11:46 schrieb Andy Furniss: >>>>>>> >>>>>>> >>>>>>> I think you are right about the slices, the failing vids are >>>>>>> blu-ray/tv. >>>>>>> >>>>>>> >>>>>>> >>>>>>> https://drive.google.com/file/d/0BxP5-S1t9VEEZlozcjVUZ1lDbWM/view?usp=sharing >>>>>>> >>>>>>> >>>>>>> >>>>>> Thanks for the link, if you have time please give the attached patch a >>>>>> try. >>>>>> >>>>>> It should fix the issue, but I currently don't have a test system for >>>>>> VAAPI ready so I can't confirm it of hand. >>>>> >>>>> >>>>> >>>>> It doesn't fix properly. The vid will play normally after a second, >>>>> but during that second I get to see many flash frames of gpu mem. >>>>> >>>>> Lucky I chose this sample out of several as the patch does seem to >>>>> fix a couple of other previously failing vids. >>>> >>>> >>>> >>>> Though more testing shows it also regresses previously working vids, >>>> some as >>>> above, but one never "starts" and is total junk. >>>> >>>> >>>> >>> >> > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
