[vlc-devel] [Bug Report] DASH external audio (input-slave) lost after seek & M3U8 segment handling issues on Windows

Wed Apr 15 13:03:03 UTC 2026

Dear VLC developers,

I am developing a media player that streams videos from Bilibili (a Chinese video platform) using libvlc (python-vlc). I have encountered several critical issues when playing DASH streams with external audio tracks and when using M3U8 playlists for multi-segment videos. I would greatly appreciate your insights or guidance on these problems.

Environment:

VLC version: 3.0.18 (and earlier)

OS: Windows 11 (also reproducible on Windows 10)

Bindings: python-vlc

Issue 1: External audio track (input-slave) is lost after seeking in DASH streams

Description:
When playing a DASH video with an external audio track added via :input-slave, the audio works initially. However, after seeking (e.g., dragging the progress bar), the audio stream is lost and never recovers. The video continues to play silently.

Steps to reproduce:

Obtain a DASH video URL and a separate DASH audio URL from Bilibili.

Create a VLC media instance with the video URL.

Add the audio URL as a slave: media.add_option(":input-slave=" + audio_url)

Start playback. Audio and video are synchronized.

Seek to any position (e.g., player.set_time(120000)).

Observe: Audio disappears after the seek.

Relevant code snippet (Python):

media = self.vlc_instance.media_new(video_url)
media.add_option(":network-caching=8000")
media.add_option(f":input-slave={audio_url}")
media.add_option(":input-slave-async")
self.vlc_player.set_media(media)
self.vlc_player.play()
// After seeking later:
self.vlc_player.set_time(seek_ms) // Audio lost after this

Expected behavior:
The external audio track should remain synchronized after seeking.

Workaround attempted (failed):
Re-adding the audio slave after seek by calling media.add_option again does not restore audio. The only solution is to stop and reload the entire media.

Issue 2: Incorrect State.Ended and infinite loop with M3U8 multi-segment playlists

Description:
Bilibili splits videos longer than ~30 minutes into multiple DASH segments. To support seamless playback, I generate an M3U8 playlist containing all segment URLs and external audio options via #EXTVLCOPT. However, when seeking or when VLC transitions between segments, VLC repeatedly emits State.Ended events, causing my player's single-loop logic to constantly reload the media, resulting in an infinite loop.

M3U8 example:

#EXTM3U
#EXT-X-VERSION:3
#EXTVLCOPT:input-slave=http://127.0.0.1:8800/audio
#EXTVLCOPT:input-slave-async
#EXTINF:360.0,
https://.../segment1.m4s
#EXTINF:360.0,
https://.../segment2.m4s
#EXT-X-ENDLIST

Log excerpt showing the loop:

2026-04-13 21:20:48,537 - INFO - Detected playback end: position=380860/695001, state=State.Ended
2026-04-13 21:20:48,538 - INFO - Handling playback end, current mode: SINGLE_LOOP
2026-04-13 21:20:48,538 - INFO - Replaying in single loop mode
2026-04-13 21:20:49,083 - INFO - Detected playback end: position=380860/695001, state=State.Ended
...

Observations:

The issue occurs even when seeking within the same segment.

VLC reports State.Ended while the current position is far from the actual end of the stream.

This does not happen with single-segment DASH or FLV streams.

Issue 3: HTTP 416 errors on audio stream seeking (proxy-related)

Description:
To work around Bilibili's referer restrictions on the audio CDN, I run a local HTTP proxy that forwards audio requests with proper headers. When VLC seeks in the audio stream, it sends a Range request. The upstream CDN sometimes returns 416 Range Not Satisfiable, causing the proxy to fail and VLC to lose audio. My proxy handles this by retrying without the Range header, but the initial failure still disrupts playback.

Proxy log:

2026-04-12 14:08:45,674 - ERROR - Audio proxy upstream error: HTTP 416 - Requested Range Not Satisfiable

Additional Context:

FLV fallback works perfectly: When using FLV streams (which mux audio and video), seeking and playback are completely stable. However, FLV is limited to 720p on Bilibili.

Bilibili's CDN requires specific Referer and Origin headers for audio streams, which is why the local proxy is necessary.

Questions:

Is there a known limitation with input-slave and seeking in DASH streams? Could this be improved in future VLC versions?

Why does VLC emit State.Ended incorrectly during M3U8 segment transitions or after seeking? Is there a recommended way to handle multi-segment DASH with external audio?

Are there any additional media options or workarounds we could use to stabilize DASH+external audio playback?

I am happy to provide sample streams (with authentication tokens removed), full debug logs, or test builds to assist in debugging. Thank you for your time and for maintaining such an excellent media framework.

If you need to contact me again, please send it to my personal email：1308413466 at qq.com

Beside，Because I am from China, I hope to provide feedback anonymously. If you are interested in this feedback, you can ask me for details, including some source code. I look forward to your reply!

Best regards
A student from China engaged in personal development.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20260415/b6531d01/attachment.htm>