wader
feat: Seek - Setup
I'm currently opening the stream up with VLC. But the player has no progressbar. Let's add one.
Dear maintainers, I'll need your help in properly testing this. I've ran the u-tests locally successfuly.
Hey, interesting, so does this support actual seeking? or is it mostly to make it possible for a player to show progress? a bit late here so will have deeper look at the PR tomorrow. My gut feeling is that non-exact content length or range headers seems like it could cause weird issues? 🤔😬
I'm setting this PR to draft since initial testing of the produced container yielded no progressbar and no max length. clicking randomly on the supposed progress bar didn't scroll either (stopped for a bit but continued afterwards).
Wondering what the root cause would be..
Aha i see 👍 yes with the way ydls works by "on-the-fly" transcode or transmux i think seeking will be very hard or very slow to achieve as it's trick to predict how large things will be and also in some cases the encoder might not even be deterministic.
As ydls at the moment do not care about range requests it will just start from the beginning for each request.
Hi @wader,
I went through the commit history and it appears you didn't implement this feature explicitly. But latest VLC for Mac v3.0.21 Vetinari (Apple Silicon) now has a progress bar and scrolling works 🎉 :
I'm hosting this in kubernetes and in VLC can just open a stream using Open Network -> https://video.galos.one/https://www.youtube.com/watch?v=--YEaUdrWnU
Hey, happy new year! no i haven't worked on this. Nice, so how does it work? progressive as in VLC will buffer and the duration will keep increasing while it's downloading?
Hey, happy new year! I assume this is some stream metadata that is by default there. Since you're not computing it/setting it/copying it explicitly, it looks like it was always there and the new VLC version now consumes it, whereas it previously didn't.
I think it's not related to how much it's downloaded because you can scroll in the stream, so the number of downloaded bytes is arbitrary.
The scrollbar progression seems therefore to be time-based based on the assumption about the metadata above.
Do you also think we can now close this draft?
Ah i see. How fast is it to seek? ydles dosen't care about range headers so does it restart the download and discard until the seek point?
Mm guess we can close this one
Ah i see. How fast is it to seek?
It takes an initial 10s to start and then about 5s to seek at a random position in the stream. But I think transcoding is also taking up a couple of seconds and further optimizations can be done there.
I think this can be further optimized by reading in the buffer size from the config file and reducing it. There are some hard-coded buffer sizes which would require small refactoring.
Potentially have an initial small size for the buffer (fills up fast and can be immediately served) and then gradually increase it.
It takes an initial 10s to start and then about 5s to seek at a random position in the stream. But I think transcoding is also taking up a couple of seconds and further optimizations can be done there.
Huh that is quite fast 👍