Getting MFX_ERR_DEVICE_FAILED on h264 decode

[anderson__eric]

I've followed the Quicksync sample_decode project and simple_decode tutorial available online. I can't seem to get those to compile (might take a look at getting those to work tomorrow), and the binaries made available for sample_decode outright do not work on my machine. I am able to compile and utilize the library with my program though; I had to make a build from the source made available in the Media SDK 2018 R2 installation, since I needed a library built with /MD (Code Generation) enabled.

I have an i7-8700K with iGPU enabled, and set as the primary adapter. I do have a secondary NVIDIA card, and I've been playing with arrangements just to try to get this to work.

Before I get into that, I've also tried testing to see if my machine would work with Quicksync on other verified applications. I have a build of FFMPEG that I know -used- to work with h264_qsv prior to some windows updates / intel driver updates, but today I get an error of (-3) unsupported. I also have a build of OBS that doesn't seem to work with QSV. The most recent stable version of OBS also doesn't seem to work encoding with QSV.

That might be it's own rat's nest in itself, so let me jump into the problem I've been having on the code side.
 

    mfxSyncPoint syncp;
	mfxFrameSurface1* mfxOutSurface = NULL;
	std::shared_ptr<mfxFrameSurface1> workingSurface = NULL;

	if(MFX_ERR_MORE_SURFACE == sts || MFX_ERR_NONE == sts) {
		workingSurface = GetFreeSurface(mfxFrameSurfaces); // Find free frame surface

		if(workingSurface == NULL) {
			gConsole->error("No free surfaces to work on");
			return;
		}
	}

	// Decode a frame asynchronously
	sts = mfxVideoDecode->DecodeFrameAsync(&mfxBts, workingSurface.get(), &mfxOutSurface, &syncp);

	// Ignore warnings if output is available,
	if(MFX_ERR_NONE < sts && syncp) {
		sts = MFX_ERR_NONE;
	}

	MFX_ERROR_CHECK_NORET(sts, "Failed to decode frame");

	if(sts == MFX_ERR_NONE) {
		// Synchronize. Wait until decoded frame is ready
		sts = mfxVideoSession.SyncOperation(syncp, 60000);

Here's a snippet of where I'm having problems. The MFXVideoSession seems to have initialized fine, the version is 1.27, codec is MFX_CODEC_AVC, IOPattern is set to MFX_IOPATTERN_IN_SYSTEM_MEMORY | MFX_IOPATTERN_OUT_SYSTEM_MEMORY, AsyncDepth is set to 1 (although this doesn't really matter).

DecodeHeader seems to work fine, it gets me mfxVideoParams that are appropriate to what I'm expecting out of the video. DecodeFrameAsync gets me an MFX_ERR_NONE, which I'm expecting - but when I get to SyncOperation, I get an MFX_ERR_DEVICE_FAILED.

Can anyone provide some insight on the problem I'm having?

[anderson__eric]

Scratch that. I found my issue - the working surface did not have a properly sized buffer.

[anderson__eric]

I have another question in regards to quicksync decoding.

When the decoder receives an IDR frame to reset the video stream to a new reference position - a lower resolution frame than the originally configured one tends to come out fine. However, when I send an IDR frame that is of a larger resolution, the picture comes out with severe artifacts, as if it skipped the IDR frame entirely (and is only processing P frames afterwards).

In between the resolution resizing, the decoder is reset - the IDR frame comes with new SPS/PPS info, and is closed/reinitialized with new buffers and surfaces, like how ResetDecoder() works in pipeline_decode.cpp of the sample_decode project.

I have tested this stream with FFMPEG's default h264, which handles the same h264 stream (with extra SPS/PPS data) just fine.

[Mark_L_Intel1]

Hi Eric,

Based on my understanding of the architecture, the reset should happen in the hardware level and you don't need to call reset explicitly; except you really change the video stream. So please double check the logic in sample_decode.

As MSDK is using the hardware decoder, all the consequence you observed should happen when you configure the decoder before the loop, so you can take the videoParams passed in when you do the configuration between reset call and compare it with videoParams at the same place in sample_decode, I would think there should be some difference.

Mark