Reset VPP

Reset VPP


i'm trying to reset the vpp for allowing dynamic input and output resolutions. MFXVideoVPP_Reset returns MFX_ERR_NONE. RunFrameVPPAsync now returns MFX_ERR_INCOMPATIBLE_VIDEO_PARAM, which isn't even documented in the manual.

If i reset the VPP with close and init it works fine. the only difference i can see in the trace is that vpp.RunFrameVppAsync.out.Data.Locked is set to 1 instead to 0. the problem is that the close/init workaround takes quite some processing time. what am i doing wrong? is resetting the vpp actually faster?






4 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

I am having a very similar problem, except I am only trying to change the VPP input pixel format. The output format stays the same and gets passed to the encoder. I am trying to append 2 clips, the first is RGB32 the second is NV12, both are identical in size.

This is the block of pseudocode that runs when I call MFXVideoVPP_Reset(), which works fine but running the VPP w/ the new param causes errors:

// Write out the delayed frames in the VPP and do any required encoding

... etc usual stuff no need to pollute the example - it runs  the VPP w/ NULL frames, passes it along to the encoder, and muxes.


// Update the VPP params w/ the new values
if (srcInfo->format & RFMT_ISYUV)
    VPPParams.vpp.In.FourCC = MFX_FOURCC_NV12;
else if (srcInfo->format & RFMT_ISRGB)
    VPPParams.vpp.In.FourCC = MFX_FOURCC_RGB4;
VPPParams.vpp.In.ChromaFormat = MFX_CHROMAFORMAT_YUV420;    // its YUV420 for both YUV and RGB


// Use updated params to get required surface alloc info from the SDK
mfxFrameAllocRequest VPPRequest[2];   // we'll only use the 1st entry in the array in this case
memset(&VPPRequest, 0, sizeof(mfxFrameAllocRequest)*2);
sts = MFXVideoVPP_QueryIOSurf(session, &VPPParams, VPPRequest));


// Add additional surfaces as shown in the 2014 SDK
VPPRequest[0].NumFrameSuggested += MYDEPTH - 1;
VPPRequest[0].NumFrameMin = VPPRequest[0].NumFrameSuggested;


// Reinitialize the VPP with the new params; this frees any remaining locks on the input surfaces
sts = MFXVideoVPP_Reset(session, &VPPParams));


// Free the old surfaces to the VPP input
delete pmfxSurfacesVPPIn;


// Allocate new VPPin surfaces for the new format
sts = DXAllocator->Alloc(DXAllocator->pthis, &VPPRequest[0], &mfxResponseVPPIn);
pmfxSurfacesVPPIn = new mfxFrameSurface1[mfxResponseVPPIn.NumFrameActual];
for (mfxU16 i=0; i<mfxResponseVPPIn.NumFrameActual; i++)
    memset(&pmfxSurfacesVPPIn[i], 0, sizeof(mfxFrameSurface1));
    memcpy(&(pmfxSurfacesVPPIn[i].Info), &(VPPParams.vpp.In), sizeof(mfxFrameInfo));
    pmfxSurfacesVPPIn[i].Data.MemId = mfxResponseVPPIn.mids[i];


// Grab a new available VPP input surface since we wiped out the old ones
surfIdxVPP = getFreeSurfaceIndex(pmfxSurfacesVPPIn, mfxResponseVPPIn.NumFrameActual);
surfIn = &pmfxSurfacesVPPIn[surfIdxVPP];
pInfo = &surfIn->Info;

And then it's pretty much back to doing the usual stuff - lock the input surface, copy pixel data into the staging surface, unlock the surface, get the next free output VPP surface, and call MFXVideoVPP_RunFrameVPPAsync() with the input and output surface as params.

When I "hack" the code so it still does the Reset but doesn't change the pixel format, it works to completion. So I know it's not simply the act of freeing and reallocating the input VPP surfaces that is causing the error. There seems to be something specific about switching the VPP from converting RGB32->NV12 to simply going from NV12->NV12.

Are there any concrete examples of using MFXVideoVPP_Reset() anywhere?

Tony Pabon (Intel)'s picture


Thank you for the detail information.  I am looking into this and will report my findings.


Has there been any new info regarding resetting the VPP discovered? I am still unable to call MFXVideoVPP_Reset() with modified input params and have MFXVideoVPP_RunFrameVPPAsync() not return an error.

Login to leave a comment.