Tweet
In case anyone else has the same problem.
We had a customer report of video corruption in the BurnInTest Video Playback test in Win11
We reproduced the problem, but only when there is a debugger attached to the process playing back the video. Example debugger applications are Visual Studio, WinDbg, etc..
The problem was also only seen with H264 video encoding. Using other H264 videos gave the same result. Using a FMP4 as an example, didn't have the problem.
The problem happened on Intel and AMD systems. So probably not a hardware codec issue.
Using an Open Source DirectShow player, using source code provided by Microsoft also gave the same video corruption, but only if the program was running with a debugger attached and playing back a H264 encoded video.
Opensource playback example app is here
https://github.com/microsoft/Windows...ShowPlayer.cpp
So the problem happens with multiple playback applications and multiple videos.
Note that Microsoft provide multiple different APIs for video playback. Some tools might also do their own decoding and rending. So not all playback apps will be using DirectShow.
(Note: In the medium term we'll look at providing other an option to use a different Windows API for playback in BurnInTest, to allow testing of more options in Windows).
Conclusion:
It is a Windows bug in Direct Show.
Work-around solution:
Don't run a debugger in the background and / or use a test video with different encoding.
Example corruption:
Corrupted video playback in BurnInTest
Corrupted video playback in open source tool
Example of playback without corruption (for comparison)
We had a customer report of video corruption in the BurnInTest Video Playback test in Win11
We reproduced the problem, but only when there is a debugger attached to the process playing back the video. Example debugger applications are Visual Studio, WinDbg, etc..
The problem was also only seen with H264 video encoding. Using other H264 videos gave the same result. Using a FMP4 as an example, didn't have the problem.
The problem happened on Intel and AMD systems. So probably not a hardware codec issue.
Using an Open Source DirectShow player, using source code provided by Microsoft also gave the same video corruption, but only if the program was running with a debugger attached and playing back a H264 encoded video.
Opensource playback example app is here
https://github.com/microsoft/Windows...ShowPlayer.cpp
So the problem happens with multiple playback applications and multiple videos.
Note that Microsoft provide multiple different APIs for video playback. Some tools might also do their own decoding and rending. So not all playback apps will be using DirectShow.
(Note: In the medium term we'll look at providing other an option to use a different Windows API for playback in BurnInTest, to allow testing of more options in Windows).
Conclusion:
It is a Windows bug in Direct Show.
Work-around solution:
Don't run a debugger in the background and / or use a test video with different encoding.
Example corruption:
Corrupted video playback in BurnInTest
Corrupted video playback in open source tool
Example of playback without corruption (for comparison)