Bug: some MP4s hang on upon load/tuning to

[StratoSTARbyHIRO]

Certain MP4 files loaded from an HTTP server result in the video file hanging on the first frame, and the audio glitching continuously, until the user switches browser tabs for about three seconds, and then the video begins to play properly.

Changing simulator channels, or interacting with the window does not rectify the issue, only switching browser tabs does. Even unfocusing the browser window and refocusing results in no change.

Any insight or anyone else encountering this issue?

[alexdresko]

@StratoSTARbyHIRO can you provide a sample mp4?

[StratoSTARbyHIRO]

@alexdresko Hey there, here is a sample URL for an MP4 that this issue exists with (in Google Chrome), it does not exist in Mozilla Firefox to my knowledge.

Video: https://epsilon.projectaries.net/music.mp4

[zshall]

Taking a look now; the mp4 you're using appears to be a video stream as the duration continues to increase as I'm playing it. That should be supported, though usually there's an m3u8 file to accompany it.

But yeah I see exactly what you're seeing; it's choking on those first few frames until the window loses focus.

When accessing the file directly in a Chromium browser it does stutter a bit on first play. Under the hood of TVS we use the Vidstack player for all video and if I play it like a normal MP4 it does tend to buffer for a bit before starting, but it doesn't experience the same bug that TVS has.

Continuing to investigate!

[zshall]

So this is interesting; the content stops getting requested until the tab isn't visible. The "Content Download" has been going for probably 30 seconds but there's only 3.62 seconds of video. If I tab away and come back after a few seconds the timer jumps ahead; it's like it's being stalled out.

[StratoSTARbyHIRO]

Indeed! if you view the same link raw within Google Chrome this does not happen at all, the video buffers out and then playback begins as expected. Do you think this could be a Google Chrome logic error (having a middle program/script perform the playback instead of Chrome itself), or an error in the way the Television Simulator 99' is handling the playback of the specific configuration of MP4 in general?

Deffo some interesting stuff!

Additionally, I should note it seems like this happens with any MP4 stream despite differing sources (as long as the MP4 Stream, is a livestream and originating from MistServer). If you need any codec configuration settings I can provide those as well, in case there is a codec specific error occurring here.

[zshall]

Thanks for the info! Sounds like you might operate a streaming server or know the person who's running it; would be good to chat on Slack to test a few things out. I'm not familiar with MistServer but it says it supports HLS streaming as well as a few other protocols; that might be a workaround.

I've tried making an m3u8 file for the MP4 stream to see if that helps but all my player is doing is refusing to play that at all while VLC plays it fine. Continuing to look around. Does the audio play for just a repeated fragment on your machine till you change focus? Almost feels like the rest of the content isn't being requested since it thinks it's done; I wonder if the content was part of a loop whether it'd skip after a single frame; that could explain a thing or two...

[zshall]

I've fed some info into ChatGPT about this and it sounds like it may be related to the broadcast format and the way the browser interacts with it:

The ffprobe output strongly suggests this MP4 is susceptible to the "moov atom at the end" issue, which would explain the exact > playback behavior you're seeing.

🔍 Key Indicators in the Output

1. format_name=mov,mp4,...
   ✅ This confirms the container is a standard MP4. Good.

2. duration=5.066000 but size=N/A, bit_rate=N/A
   ⚠️ This typically means ffprobe was unable to read the entire file or the moov atom is at the end — which is common in files > that aren't faststart-optimized.
   When the moov atom is at the end:

• Browsers must buffer the entire file to find the index.
• This breaks progressive playback and causes stalling — especially in Chrome.

3. start_pts=66 / start_time=0.066000 for video stream
   🟡 Not necessarily a problem, but it suggests a slight audio-first offset. Combined with other issues, this can increase glitching > likelihood.

4. probe_score=100 but size=N/A
   🔴 The format is recognized, but ffprobe couldn’t read the full metadata — again pointing to the moov atom being at the end or the > file being served in a way that doesn't allow proper seeking.

It also says "if MistServer is being used and its MP4-on-HTTP behavior is causing playback stalls due to moov atom placement, switching to HLS or DASH is highly recommended for browser-based streaming."

[StratoSTARbyHIRO]

Thanks for the insight! I looked into MistServer and the possibility of different outputs, and have found that so far indeed going with DASH video is working, if I use this for example: https://epsilon.projectaries.net/cmaf/music/index.m3u8 Television Simulator picks it up and plays it properly!

Thank you again for the insight, from now on and for others wonder that also use MistServer it deffo needs the DASH video to play properly, rather than raw MP4.

If you still would like to debug the raw MP4 issue, let me know! I joined the slack (and found that it costs unfortunately to see history, and worry my contributions to the debugging will be lost should I need to reference back to it in the far future.)

[zshall]

Sounds good! Enough people over the years have asked for a Discord so I decided to make one today; the message limitations on Slack have been getting annoying for a while and it's prohibitively expensive to pay since it's a public one, which they don't really officially support.

I'll update the streaming documentation to explain what isn't working and why. I've opened up the project's wiki as well to everyone so that the docs can be augmented with anything that should be in the docs but isn't yet.

Based on what I've been reading I'm not sure that there's a good solution for fixing the mp4 settings and that HLS or DASH should be used instead. I'm gonna leave this issue open for now in case anyone has any other ideas though.

[StratoSTARbyHIRO]

Sounds like a plan! I definitely agree when it comes to Slack, it's a little hit and miss when it comes to being able support projects I think, but that's from personal experience. I joined the Discord, hope to be able to see it grow! :)

As per the issue, from the looks of it, it may very well be format configuration specific, it may also be to do with the integrated video handler that Television Simulator 99 uses as well. DASH video (in my experience so far) seems to be much more stable and reliable, so that's what I recommend going with especially if MistServer software is being utilized to create and transmit the stream itself.

I deffo appreciate your attention to this and your help!

[zshall]

While developing TVS Studio I've seen the pattern enough over the last few months with files hanging on playback to fully understand that ChatGPT was right about the file structure being the issue. This happens with webm and mp4 files just the same.

The only fix possible here is to document this so that everyone is aware of what to do when it happens.

To close this issue I'll:

• Create a guide in the docs explaining what I found out about file formats and HTTP range requests