[Bug] setActiveTracks(audio) causes premature EOF ~9s before file end on MKV with multiple video streams

[zhouxiansheng]

Summary

When playing an MKV with multiple video streams (main feature + mjpeg cover poster), calling setActiveTracks(MediaType.audio, ...) (a.k.a. activeAudioTracks in the fvp/Flutter binding) triggers a premature EOF: MediaStatus.End is set ~9s before the real file end, and the remaining content is fast-forwarded in 1-2 seconds.

This is a native-layer bug in mdk.dll, confirmed in:

• mdk-sdk 0.36.0.0 (commit 6b16dfa, shipped with fvp 0.37.2)
• Latest nightly (commit 8cc31e7, 2026-06-18) — NOT fixed
• Reproduced in NipaPlay (open-source, same mdk.dll) when user switches audio tracks → confirms it's not app-specific.

Reproducible Sample

Attached: mdk-multistream-bug-sample.zip (13.2MB) — a 27-second clip from the original file. Structure (via ffprobe):

index	type	codec	notes
0	video	hevc	3840x2076, main feature
1	audio	dts
2	audio	dts
3	audio	ac3
4-11	subtitle	pgs	8 tracks
12	video	mjpeg	1000x1500, single-frame cover poster

The key trigger: 2 video streams (main + mjpeg poster). This sample reproduces the bug reliably in a minimal test harness.

Reproduction Steps

final p = mdk.Player();
p.videoDecoders = const ['MFT:d3d=11', 'D3D11', 'DXVA', 'FFmpeg', 'dav1d'];
p.media = 'sample.mkv';
await p.prepare();
await p.updateTexture();

// THE TRIGGER: switch audio track
p.activeAudioTracks = const [1];

p.state = mdk.PlaybackState.playing;
// poll p.position every 250ms → observe ~9s early jump + End flag

Expected vs Actual

Expected: position increases monotonically; End set near real file end (remain ~0).

Actual (logged every 250ms):

remain=9093  end=false   ← playing normally
remain=5589  end=false   ← JUMP: position skipped ~3500ms in one tick
remain=125   end=false   ← JUMP to near end
★ END FLAG => true (remain=125ms)
remain=42    end=false
```

## Control Experiments (exhaustive A/B testing)

Bug triggers **iff** `activeAudioTracks` is called. None of these reproduce it:
- Playing WITHOUT `setActiveTracks(audio)` (default 1st track) → **no jump**, `End` at remain≈4400ms
- `setVolume`, `setProperty(avformat.*)`, `setDecoders`, `setBufferRange`, dispose+rebuild Player, eager position timer — **none** cause the jump
- Single-video-stream files — **unaffected** even with `setActiveTracks(audio)`

## Hypothesis

For multi-video-stream files, `setActiveTracks(audio)` corrupts the demuxer's EOF logic — the "all streams exhausted" condition fires ~9s early, then flushes remaining packets rapidly.

## Ask

Could the team investigate the demuxer's EOF evaluation when multiple video streams exist AND `setActiveTracks(audio)` has been called? This breaks audio switching for any retail/remux MKV with an embedded cover poster — a very common scenario. Thank you!

[mdk-multistream-bug-sample.zip](https://github.com/user-attachments/files/29310888/mdk-multistream-bug-sample.zip)

[wang-bin]

mdk-multistream-bug-sample.zip is missing

[zhouxiansheng]

mdk-multistream-bug-sample.zip is missing

@wang-bin
mdk-multistream-bug-sample.zip
我刚刚测试了，可以下载呀