AVC1 and VC1 decode issues with new graphics driver (2509)
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?
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.
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?