First 9 seconds of video are always at a low streaming resolution.

[TheShankar]

Describe the bug
First 9 seconds of any video are always served at a lower image quality, I assume it's running a 320p or similar resolution.

To Reproduce

1. Play any video, notice how after 9 seconds the image becomes better/crisper
   https://bsky.app/profile/shvvhs.bsky.social/post/3l3yxnkds232n

Expected behavior

1. System should store if the user is able to stream videos at the best quality possibly, and then use these settings for subsequent videos.
2. User should be able to select which resolution to watch the video. (suggestion)
3. Once the video loops, if any of the parts were offered at a lower resolution, they should be "updated" to the same resolution as all the later parts. (suggestion)

Screenshots
using download sites (like Cobalt), the video gets downloaded at the maximum quality available. Which confirms the issue is when the video is being streamed and not when it's being encoded.

Details

• Platform: Chrome, Firefox, With and Without VPN.
• Platform version:
• App version:

Additional context

[TheShankar]

I think this issue is what causing this other issue: #5306

But since they are ultimately different requests (no filter/nearest neighbour/pixelated video player setting) I decided to make this separate bugreport.

[HeyItsLollie]

The fact that this affects the first nine seconds is weirdly consistent. I saw this affect my own uploaded video, and was able to observe it on another random video on my timeline.

The player makes no attempt to reload data from the video stream, so you always end up with a video that has multiple streams of varying quality mushed together. I would definitely prefer that the video player just preload the best available stream, and then play when it's able.

[AdrianoCahete]

Player gets the 360p version, then change to 720p when loaded. This took ~9s to occur:

I think this is because the loading for 720p playlist starts blocked by something for 260ms, while the 360p playlist starts immediately. Did not see the code, but app may add a preload tag for video, then this maybe will fix that?

[mozzius]

On web, is only allowed to load in hi res once you click on it, at which point it determines the quality based on network conditions

[mauricioabreu]

Some HLS players start playing from the first defined variant. In that case, it is the one with the lowest bandwith/ratio.

Try it.

From this:

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-STREAM-INF:PROGRAM-ID=0,BANDWIDTH=655600,CODECS="avc1.640014,mp4a.40.2",RESOLUTION=202x360
360p/video.m3u8?session_id=crjdl1rkadms72oe0ol0
#EXT-X-STREAM-INF:PROGRAM-ID=0,BANDWIDTH=1240800,CODECS="avc1.64001e,mp4a.40.2",RESOLUTION=406x720
720p/video.m3u8?session_id=crjdl1rkadms72oe0ol0

To this:

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-STREAM-INF:PROGRAM-ID=0,BANDWIDTH=1240800,CODECS="avc1.64001e,mp4a.40.2",RESOLUTION=406x720
720p/video.m3u8?session_id=crjdl1rkadms72oe0ol0
#EXT-X-STREAM-INF:PROGRAM-ID=0,BANDWIDTH=655600,CODECS="avc1.640014,mp4a.40.2",RESOLUTION=202x360
360p/video.m3u8?session_id=crjdl1rkadms72oe0ol0

[mozzius]

We want the lowest bandwidth option to play initially, so that we don't overfetch hi res videos that you're just scrolling past and are not interested in, this is not a mistake

[surfdude29]

We want the lowest bandwidth option to play initially, so that we don't overfetch hi res videos that you're just scrolling past and are not interested in, this is not a mistake

This makes complete sense for the default, autoplay setting. Would it be possible to have a different behaviour for when a user has autoplay disabled? When that's the case, the user is expressing a definite intent to watch the video by clicking or tapping to play it, and it would be nice in that situation if the highest res video stream could be played from the beginning.

[mozzius]

Makes sense, we don't have much control over the HLS settings on native currently (but we will next update thanks to Hailey's work, so we can tweak it then)

[HeyItsLollie]

We want the lowest bandwidth option to play initially, so that we don't overfetch hi res videos that you're just scrolling past and are not interested in, this is not a mistake

I assumed this was the intent, but even if you do intentionally stop scrolling to watch a video, that first nine seconds of low-res video is retained. Does the next update help correct for this behavior?

[Paarsec]

This could potentially be really tough for video artists. Would there be the possibility of having the second replay of the video trigger a higher quality version? Thanks.

[edueocara27]

We want the lowest bandwidth option to play initially, so that we don't overfetch hi res videos that you're just scrolling past and are not interested in, this is not a mistake

Yes, but even with autoplay turned off and even clicking on the post, which should indicate the user wants to watch the video, this problem persists.

I believe a mechanism should be created to trigger high quality, such as clicking on the post or replaying the video, which would indicate the user wants to watch the video.

I also think another solution would be to create a setting in the player that allows the user to manually select the video quality, as already exists on Twitter.

[mozzius]

Ok, I've come to realise this is very much a bug. There's a feature request in the hls.js repo (see below) but I'll see what I can do to work around it

video-dev/hls.js#4553

[FreyaHolmer]

somewhat related to this - are there any widely supported video compression formats made for stuff with flat colors?

I make a lot of content that's basically looping ~4 second .gifs with clean/flat/vector graphics style colors, and every time it converts to mp4 it ends up looking worse and sometimes even being a larger file size ;-;

[TheShankar]

somewhat related to this - are there any widely supported video compression formats made for stuff with flat colors?

I make a lot of content that's basically looping ~4 second .gifs with clean/flat/vector graphics style colors, and every time it converts to mp4 it ends up looking worse and sometimes even being a larger file size ;-;

I think our "best chance" was the Animated WebP format that (AFAIK) only Tumblr really uses! would preserve your image quality and probably not be as big as MP4... But it's not really a video compression, so I suppose that's cheating? lol. (would be neat if Bluesky would consider adding support for it, tho lol_

Other than that I always feel on the same boat as you video-format-wise: worse image quality, higher filesize. I do recall in the past some compression formats were pretty great with this stuff, but seems like they all died out.

[HeyItsLollie]

I think our "best chance" was the Animated WebP format that (AFAIK) only Tumblr really uses!

Fwiw, Mastodon and Cohost (RIP) also support WebP! It's a solid format that's worth investigating. We're also still waiting on native GIF uploads (#1047), which I hope would be useful for smaller looping GIF-like content.

[TheShankar]

@HeyItsLollie Thanks for the heads up! I did try to upload some Animated WebP to Mastodon but it doesn't really play there. But maybe I did do something dumb? always possible haha.

I did create a separate Animated WebP request support here, did cite your original request in one of the comments on the Gif thread as well!

[Paarsec]

The issue is still present for me (on web, while it seems perfectly fine now on mobile!), should I open a new ticket or is reporting it here fine?
Also worth noting that it does not load in higher quality even after clicking on videos, just a heads-up.

[TheShankar]

@Paarsec I think you should make a new ticket, as this one is closed and probably won't be seen. And yeah, I second your notion, still the same for me here.

[Paarsec]

Link to new ticket here: #5746

[ICEknigh7]

@mozzius That doesn't seem to have fixed the problem.

[mozzius]

Yep, looking at it today. It does work, just only for long videos

[mozzius]

Fixed by #5996 🤞