15.45 drivers breaking change (bug) in H264 decoding

[alex78]

Hi all,

the 15.45 driver version introduces a breaking change (bug) in H264 decoding. It is the second time, that new drivers broke our app. In short, for some H264 streams the DecodeFrameAsync function now returns MFX_WRN_DEVICE_BUSY with no reason and without any changes in our code. We can reproduce the behaviour on a Win 10 Skylake computer with the driver package win64_154025.4463 (works well) and win64_154510.4542 (introduces the issue).

The sample_decode app is too complex to reproduce the problem easily, because it handles the "device busy" state and thus hides the issue. Moreover, we are always passing discrete samples for decoding, forcing the output by calling DecodeFrameAsync with a NULL bitstream if necessary and running SyncOperation immediately. So we created a minimalistic app that helps to reproduce the issue easily.

1. Unpack the small repro project (no error checking and designed mostly only for the attached h264 file). It might be necessary to update the lib directories to find the libmfx.lib to link against.

2. Run it with the attached h264 file as a command line parameter.

3. With older drivers it will decode all the frames and output the result.

4. With newer drivers it will break on MFX_WRN_DEVICE_BUSY (with no reason for it) while decoding the second frame in the file.

The (even more) interesting thing is, that this problem does happen only for some H264 bitstreams, not for all, but was never seen with the older driver testing hundreds of streams.

Thanks for looking into this.

Alex

[alex78]

Hi all, well, so we have identified a breaking change (or bug) back in February, which can still be reproduced with latest drivers  - 15.45.19.4678. We have also created a simple to use repro. Is no one interested in it? Especially some Intel guys who might be monitoring this forum...

Thanks.

Alex

[ViCue_S_]

they have hired AI to host the forum, but it yet in learning stage. can say only "Thanks so much, this is a valuable feedback”. It is making progress, be patient!

[Sergey_S_Intel1]

We have assigned and engineer to take a look to the problem. Please wait results in a couple of days.

[alex78]

Hi Sergey,

I am not sure what you meant by "a couple of days" - now it's almost 50. We found a workaround  for this (breaking) change, but we are still unsure about the nature of the problem. Any chance for a resolution here?

Thanks.

Alex