Share via

Glitchfree HD Video Playback on Battery (DC) Power Source ( Manual on mobile systems )

  • Article

Important

   This test requires supplemental content. You can find this content in the 'Windows HLK supplemental test content' section at the following location:

 

The manual test verifies that a mobile system on DC power mode is capable of playing protected and unprotected High-Definition content with no perceivable glitch during playback.

Test details

   
Specifications
  • System.Client.VideoPlayback.GlitchfreeHDVideoPlayback
Platforms
  • Windows 10, client editions (x86)
  • Windows 10, client editions (x64)
  • Windows 10, client editions (Arm64)
Supported Releases
  • Windows 10
  • Windows 10, version 1511
  • Windows 10, version 1607
  • Windows 10, version 1703
  • Windows 10, version 1709
  • Windows 10, version 1803
  • Windows 10, version 1809
  • Windows 10, version 1903
  • Next update to Windows 10
Expected run time (in minutes) 20
Category Scenario
Timeout (in minutes) 60
Requires reboot false
Requires special configuration false
Type automatic

 

Additional documentation

Tests in this feature area might have additional documentation, including prerequisites, setup, and troubleshooting information, that can be found in the following topic(s):

Running the test

Before you run the test, complete the test setup as described in the test requirements: System Client Testing Prerequisites.

This test requires manual intervention if the mobile system is plugged into an AC power source when the test starts.

Troubleshooting

For generic troubleshooting of HLK test failures, see Troubleshooting Windows HLK Test Failures.

For troubleshooting information, see Troubleshooting System Client Testing.

More information

The HLK GlitchFree test plays back four video clips in a Media Engine-based test playback application. The content is played back in Fullscreen while ETW logging is enabled in the background. After each scenario, the test post processes the ETW log and extracts metrics, which are used to determine whether the test passes or fails.

Pass/Fail Criteria & Metric Details

Glitch Metrics

  • Video Glitches - The Media Engine's Video renderer (SVR) detects when a frame is rendered late and it fires a video glitch event. The goal for this metric is 0. Provider and event details:

    • Microsoft-Windows-MediaEngine

    • Channel - MediaFoundationMediaEngine - 16

    • Level - win:Verbose - 5

    • Task - VideoFrameGlitch - 23

  • Dropped Frames - The Media Engine fires frame drop events when the source drops a frame. When frames are dropped, the user experiences glitchy video. The goal is 0. Provider and event details:

    • Microsoft-Windows-MediaEngine

    • Channel - MediaFoundationMediaEngine - 16

    • Level - win:Verbose - 5

    • Task - DroppedFrame - 18

  • DWM Schedule Glitches - The desktop window manager (DWM) fires a glitch event when DWM samples are rendered late. The goal for this metric is 0. The test starts tracking this event 500ms after the first PresentedFrame event (Task ID 19, Event ID 115). The test stops tracking this event 66ms after the last instance of PresentedFrame event (Task ID 19, Event ID 115). Provider and event details:

    • Microsoft-Windows-Dwm-Core

    • Channel - Microsoft-Windows-Dwm-Core/Diagnostic - 16

    • Level - win:Informational - 4

    • Task - SCHEDULE_GLITCH - 17

  • Audio Glitches - Audio glitches. Goal is 0.

    • Audio Engine Provider: a6a00efd-21f2-4a99-807e-9b3bf1d90285:0x000000000000ffff:0x3

    • ETW Classic event GUID: 2013DBB2-2F76-4B2C-950A-0C9DFAC62398

    • Event details:

      • Media: Audio Engine

      • AE Events

      • AE_GLITCH

Total Device Creation time: The total device creation time must not exceed 50ms. Total device creation time is defined as DeviceCreation + CreateVideoDecoder, where the definition of those two metrics are:

  • DeviceCreation = The latency between the following two events

    • Microsoft-Windows-Direct3D11 > Channel - Microsoft-Windows-Direct3D11/PerfTiming - 18 > Level - win:LogAlways - 0 > Task - D3D11CoreCreateDevice - 8 > Event Id - 20 (Version 0) Opcode - win:Start - 1

    • Microsoft-Windows-Direct3D11 > Channel - Microsoft-Windows-Direct3D11/PerfTiming - 18 > Level - win:LogAlways - 0 > Task - D3D11CoreCreateDevice - 8 > Event Id - 21 (Version 0) Opcode - win:Stop - 2

  • CreateVideoDecoder = The latency between the first instance of the following two events:

    • Microsoft-Windows-Direct3D11 > Channel - Microsoft-Windows-Direct3D11/Logging - 17 > Level - win:LogAlways - 0 > Task - ID3D11VideoDevice_CreateVideoDecoder - 911 > Event Id - 1722 (Version 0) Opcode - win:Start - 1

    • Microsoft-Windows-Direct3D11 > Channel - Microsoft-Windows-Direct3D11/Logging - 17 > Level - win:LogAlways - 0 > Task - ID3D11VideoDevice_CreateVideoDecoder - 911 > Event Id - 1723 (Version 0) Opcode - win:Stop - 2

Driver Metrics- The ISR/DPC duration and ISR/DPC Storm tests aim at ensuring that device drivers are well behaved. The goal is to ensure that time critical multimedia threads can run on a regular basis, with limited interruptions from ISR/DPCs.

  • ISR/DPC duration: This check is designed to validate that individual ISR/DPC duration does not exceed a 3ms threshold.

  • ISR/DPC Storm: A cumulative duration of every ISR/DPC within a 10ms window must not exceed 4ms.

GPU VSync Cadence: This case ensures that the GPU DPC VSync cadence follows a well behaved pattern. Fluctuations in GPU DPC Vysnc frequency, during media playback can result in glitches during media playback. The test criteria establishes that the cadence fluctuation should not exceed +/- 50% of the average VSync cadence window. For instance, in a 60 Hz monitor, the expected VSync DPC cadence is 16.666 ms; consequently the test will fail if any VSync DPC is fired within less that 8.3 ms from the previous one or later than 24.9 ms from the previous one. When the duration between two vsyncs is greater than 24.9ms, this often results in a perceivable video glitch. When the distance between two vsyncs is less than 8.3ms, this is often caused by the driver double firing vsyncs, or vsyncs that are a few microseconds (us) apart.

How to enable verbose ETW logging for analysis

To collect more verbose ETW logs, change the user-settable parameter 'DoFullLogging' to 'true' before running the tests.

How to preserve the ETW logs for analysis in case of failure

To preserve the ETW logs for failed test cases, change the user-settable parameter 'CopyLogsOnFailure' to 'true' before running the tests. This will also copy the ETW logs of failed test cases to the controller and be included as part of HLK package to be shared for investigation.

Using Media Experience Analyzer to analyze failed ETW logs

You can use Media Experience Analyzer (MXA) to analyze failed ETW logs. The MXA tool is available as part of the Windows ADK.

Parameters

Parameter name Parameter description
TestCycles Number of cycles to run the test for
DoFullLogging Enable flag for full logging of ETW traces in case of failure, and re-run this test.
CopyLogsOnFailure Enable flag to copy ETW log traces to subfolder 'ETWlogs' in case of failure, and re-run this test. This also copies the failure logs to hlkx package to be shared for investigation
FrameCount Minimum number of MF Events required during playback
MaxIsrDpcTime Maximum ISR Dpc time in microseconds
MaxIsrDpcStorm Maximum ISR Dpc Storm in microseconds
MaxIsrDpcLoop Maximum ISR Dpc Loop time in microseconds
GlitchCount Number of glitches acceptable during playback