Media (Intel® Video Processing Library, Intel Media SDK)
Access community support with transcoding, decoding, and encoding in applications using media tools like Intel® oneAPI Video Processing Library and Intel® Media SDK
Announcements
The Intel Media SDK project is no longer active. For continued support and access to new features, Intel Media SDK users are encouraged to read the transition guide on upgrading from Intel® Media SDK to Intel® Video Processing Library (VPL), and to move to VPL as soon as possible.
For more information, see the VPL website.
3058 Discussions

AVC1 and VC1 decode issues with new graphics driver (2509)

Ariel_G_Intel
Employee
673 Views
Aftre installing the latest Intel graphics driver (2509), large parts of my DirectShow decoder code were broken.

AVC1:
DecoderHeader returns -10 on almost all streams. MFXInit succeeds. DecodeFrameAsync fails with MFX_ERR_INCOMP_VIDEO_PARAM followed by a DecodeHeader that succeeds, a Reset that succeeds and playback is fine.
Older driver (I have 2 systems) succeeds on the initial DecodeHeader and DecodeFrameAsync works with no errors.
This was tested on the same files, same players, same MSDK version (either 2.0 or 3b4).
BTW, MSDK 3.0b4 "lost" it's AVC1 handling code from the DS plugin sample.

VC1:
Unlike the AVC1 workaround in the above issue, here I don't have a workaround.
The older driver wantedthe sequence header to be decoded after each new segment (at playback start and after every seek).
New driver will crash on the above paradigm (UMC::Vc1exception or something similar).
The new driver wants the sequence headers decoded once per session and only once.
Old driver doesn't work with the new driver behavior, it can't decode when a seek occurs.

Old driver behavior was more was aligned withH264 and MPEG2 decoders behavior. They need their sequence headers to recover from a seek/stop.

Can you shed some light on the matter?

Thanks,
Eric

Update: found a workaround for the VC1 issue. If the decoder is flushed before a Reset (e.g. after a seek), it will work well. This is not documented (flushing is optional in the docs) and behavior is different amongst driver versions.
0 Kudos
4 Replies
Anthony_P_Intel
Employee
673 Views
Hi Eric,

I've sent you internal email requesting more information.

-Tony
0 Kudos
madshi_net
Beginner
673 Views
FWIW, in my own MSDK DirectShow implementation, in order to avoid any such complications, I'm completely releasing and recreating the decoder after every seek. Works just fine without any noticeable delay. Maybe that would be a useful workaround, too?
0 Kudos
Ariel_G_Intel
Employee
673 Views
That's fine, thanks, but the Reset is not working as expected.
BTW do you kill the whole session or just the decoder?
0 Kudos
madshi_net
Beginner
673 Views
I kill and recreate everything.
0 Kudos
Reply