- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
Link Copied
4 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Eric,
I've sent you internal email requesting more information.
-Tony
I've sent you internal email requesting more information.
-Tony
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That's fine, thanks, but the Reset is not working as expected.
BTW do you kill the whole session or just the decoder?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I kill and recreate everything.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page