Investigate VTDecompressionSession DecodeFrameTest codecBadDataErr (-8969) on iOS/tvOS 26.4

[dalexsoto]

Background

In PR #24817 (Xcode 26.4 Beta 2 monotouch stabilization), we added a mitigation in:

• tests/monotouch-test/VideoToolbox/VTDecompressionSessionTests.cs (DecodeFrameTest)

The test now treats output-callback status -8969 as a known instability on iOS/tvOS 26.4 and marks the run Inconclusive instead of failing hard.

Why this issue

Review feedback requested a separate follow-up because -8969 is codecBadDataErr, and we should investigate a deterministic/fixable root cause instead of keeping a broad test mitigation forever.

PR discussion reference: #24817 (comment)

Evidence gathered

• CI triage identified MonoTouchFixtures.VideoToolbox.VTDecompressionSessionTests.DecodeFrameTest failures in iOS/tvOS simulator jobs during the Xcode 26.4 bump work.
• Failing signature observed in callback path: status -8969 (codecBadDataErr).
• Current mitigation records count of this callback status and ends Assert.Inconclusive (...) when observed.

Current code behavior (temporary mitigation)

In DecodeFrameTest:

• On iOS/tvOS 26.4+, callback status -8969 is counted and not added to failure list.
• If any such callbacks occurred, test ends as inconclusive:
  • Assert.Inconclusive ("Known decoder callback status -8969 observed ...")

Suggested investigation

• Reproduce with targeted runs on iOS and tvOS simulators:
  • SIMCTL_CHILD_NUNIT_TEST_NAME=MonoTouchFixtures.VideoToolbox.VTDecompressionSessionTests.DecodeFrameTest make -C tests/monotouch-test/dotnet/iOS run
  • SIMCTL_CHILD_NUNIT_TEST_NAME=MonoTouchFixtures.VideoToolbox.VTDecompressionSessionTests.DecodeFrameTest make -C tests/monotouch-test/dotnet/tvOS run
• Determine if the bad-data callback is:
  • simulator-only,
  • asset-specific (xamvideotest.mp4),
  • timing-sensitive in async decompression callback handling, or
  • tied to decode-session setup/format assumptions after Xcode 26.4.
• Replace the inconclusive fallback with a deterministic assertion once root cause is understood.

[rolfbjarne]

• Replace the inconclusive fallback with a deterministic assertion once root cause is understood.

Even better would be to fix the test to not produce the error in the first place (different input video? different decoding setup/configuration?)

Alternatively, this could be a bug in the underlying VTDecompressionSession class, in which case we should create an Xcode sample and report the bug to Apple.