Repository navigation
[MacOS] MTLReportFailure crash during playback #395
Description
Describe the bug
I noticed a lot of crashes on MacOS related to MTLReportFailure since September 9. It happens during video playback, on both Intel and Apple Silicon Macs. More than 600 users are impacted.
I updated fvp from 0.37.2 to 0.38.1 and mdk to 0.38.0 yesterday but unfortunately I'm still getting the same crash. I'm using Flutter 3.41.9.
Unfortunately I'm not able to reproduce on my side, so I can only share the Crashlytics stacktrace. Some users had been watching a live stream for more than 40 minutes before it crashed.
I also noticed that the mdk podspec downloads the nightly archive even with a pinned pod version. The binary in my app is 0.38.0 (git 1edab3e), while the GitHub stable archive contains 0.38.0 (git b43ab43). Could this be related? I haven't tested the stable archive yet.
Expected behavior
The app should not crash.
Log
Stacktrace (iMac M1, macOS 26.6.2)
Thread: mdk.vdec1 (instance suffix omitted). All 32 frames are listed in original order; C++ template signatures are shortened for readability. Source locations are as reported by Crashlytics.
0 libsystem_kernel.dylib __pthread_kill
1 libsystem_pthread.dylib pthread_kill
2 libsystem_c.dylib abort
3 libsystem_c.dylib __assert_rtn
4 Metal MTLReportFailure.cold.1
5 Metal MTLReportFailure
6 Metal _MTLMessageContextEndNewNSErrorOrAbort
7 Metal -[MTLTextureDescriptorInternal validateWithDevice:]
8 AGXMetal13_3 -[AGXTexture initWithDevice:desc:isSuballocDisabled:]
9 mdk MetalVideo::Private::LayerTextures::upload (vector.h:407), image offset 0x70e68
10 mdk MetalVideo::Private::LayerTextures::ensure (MetalVideo.mm:255)
11 mdk MetalVideo::render (MetalVideo.mm:419)
12 mdk MetalVideoRenderer::draw (MetalVideoRenderer.mm:116)
13 mdk VideoRenderer::redraw (VideoOutput.cpp:915)
14 mdk VideoRenderer::draw (VideoOutput.cpp:836)
15 mdk Player::renderVideo (Player.cpp:445)
16 fvp TexturePlayer render lambda / std::__invoke (FvpPlugin.mm:105)
17 fvp Player::setRenderCallback lambda (Player.h:672)
18 mdk <deduplicated_symbol>
19 mdk VideoRenderer::update (VideoOutput.cpp:422)
20 mdk VideoRenderer::process (__tree:1487)
21 mdk VideoPresenter::present (VideoPresenter.cpp:606)
22 mdk std::function<double(VideoFrame const&, RenderStatistics*)>::operator() (function.h:274)
23 mdk MediaControlPush::onProcessed (MediaControl.cpp:1564)
24 mdk MediaControlPush::onVideoReadInThread (wrap_iter.h:65)
25 mdk MediaControlPush::onVideoRead (MediaControl.cpp:1341)
26 mdk MediaControlPush::updateUniqueReaders lambda / std::__function (function.h:174)
27 mdk FrameReader::frameAvailable<VideoFrame> (FrameReader.cpp:1040)
28 mdk FrameReaderImpl::decodeLoop<(MediaType)0> (FrameReader.cpp:2615)
29 mdk FrameReaderImpl::startDecodeThread / std::__thread_proxy (FrameReader.cpp:2778)
30 libsystem_pthread.dylib _pthread_start
31 libsystem_pthread.dylib thread_start
Do you have any idea what could cause this, or which logs would help investigate?
Thanks
Activity
JulienDev commentedon Sep 20, 2026
Update: I now have both production impact data and a deterministic reproducer for this crash.
Production impact
I measured the issue across my two latest affected builds,
11.0.4 (296)and11.0.5 (297), over a seven-day period:MTLReportFailure.cold.1 / __assert_rtnFrom those values, this issue affected approximately 4% of all sessions. On
11.0.5 (297)alone, the estimated affected-session rate was approximately 3.6%.The session percentage is derived from Crashlytics' crash-free-session metric and this issue's share of fatal events, so it should be treated as an estimate rather than an exact raw-session count.
Deterministic reproduction
I can now reproduce the crash with an HLS stream that transitions between:
The crash occurs in the Metal rendering path while textures are being recreated or uploaded after the decoded frame format changes. Metal reports an invalid texture format:
The relevant stack reaches:
I reproduced it with MDK
0.38.0, git revision1edab3e. Running the same reproducer with revisionb43ab43does not crash, which strongly suggests a regression between those revisions.I investigated a defensive workaround in FVP, but it would have to infer the format transition from public state and reset the renderer heuristically. That would likely hide the symptom rather than fix the invalid Metal texture state at its source.
Could you please investigate the Metal texture lifecycle when the decoded pixel format or bit depth changes, especially the
8-bit → High10 → 8-bittransition, and ensure that incompatible cached textures and descriptors are fully invalidated before the next upload?I would be happy to help test a patched MDK build or contribute a source patch if the relevant MDK source repository is available.
wang-bin commentedon Sep 21, 2026
I can't reproduce the crash using h264 8bit -> high 10 -> 8bit. a log file can be helpful
wang-bin commentedon Sep 21, 2026
I can reproduce the crash now. On my machine h264 high 10 profile can be decoded by VT decoder. If i force FFmpeg decoder for high 10, i get the same crash. You log is still helpful, I can know your environment, for example OS version and cpu. iirc my macbook air 2014 was able to decode such videos. I also need a segment your h264 high 10 video to test
JulienDev commentedon Sep 21, 2026
Thanks. On Mac16,5 (M4 Max, macOS 27.0 / 26A428), FVP 0.38.1 + MDK 0.38.0 (
1edab3e) aborts withMTLTextureDescriptor has invalid pixelFormat (0)when playing this synthetic 8-bit → High10 → 8-bit HLS sample withvideo.decoders = ['VT:copy=1', 'FFmpeg', 'dav1d']. The same sample does not crash with MDKb43ab43. I enabled fullLevel.ALLlogging as in the issue template; the complete log and macOS crash report are linked below.wang-bin commentedon Sep 22, 2026
thanks. this crash is fixed in the latest build
JulienDev commentedon Sep 22, 2026
Thanks for the fix! I reran the reproducer with MDK 80dca5d on macOS arm64. The 8-bit → High10 → 8-bit HLS playlist looped for about 2.5 minutes without crashing. Looks fixed on my side.