Peertube: Longer videos are especially slow to start

[scanlime]

I've been putting up a lot of longer videos (archives from live streams) and, whereas there might be startup speed improvements to be had across the board, it seems like there's a special opportunity to optimize longer videos.

This might be related to the algorithm which chooses a resolution; maybe we want to be more likely to go ahead and stream the first 10 seconds at 240p while the 720p or 1080p version loads, for example.

Also, I'm not sure about the details of the mp4 header, but are there some data the player needs to download before streaming which scales with the length of the video? If so, would it be helpful to have a transcode that's both shorter and lower quality to start with, while the "real" version is still loading?

[rigelk]

Indeed, the moov atom is usually placed at the beginning of an h264 file and contains structural information that scales with the video.

As for the answer, favoring a slightly lower resolution at first is probably simpler than having special transcodes, but if you can do a benchmark that would be great!

[Chocobozzz]

@scanlime What videos? Please give us URLs so we can test.

[scanlime]

I’m trying to get a proper dev environment set up for the client so i can
add instrumentation, but i’m also happy to provide links :)

here’s the longest video i currently have, but many on this server are in
the 4-10 hour range,

https://diode.zone/videos/watch/2f1544f6-3a3b-4cd0-bb72-c57d2e2d1e9b

edit: pasted the wrong link first? or did MobileSafari copy the wrong one from the site? hmm...

[scanlime]

This might be a separate bug, but with the (12 hour) video I just posted, I can reproduce behavior where the video never loads, despite the downloads succeeding at an okay rate. Here's the setup:

1. This is on LAN, with just a hairpin NAT route between me and the server, so real network effects are not an issue.

2. Using Firefox 61.0.2 on Mac OS, server is still running beta10.

3. Firefox is set to simulate "Regular 3G" network speed, with cache disabled.

4. Navigate to the long video (https://diode.zone/videos/watch/2f1544f6-3a3b-4cd0-bb72-c57d2e2d1e9b)

Results:

User sees the load spinner forever. (Edit: Eventually the video starts, after 8 minutes or so. Doesn't play consistently)

A look at the network tab shows files downloading at an okay rate. One potential problem: The latency for an individual request is getting very high, upwards of ~20 seconds, due to queueing. If the player isn't taking this into account, it could end up blocking on I/O forever I imagine.

[Chocobozzz]

The video is very long, and the web browser needs to download many chunks to get the entire MOOV atom. So it's "normal" if the video is slow to start, especially with an high latency network.

upwards of ~20 seconds, due to queueing

We use 4 webseed connections in webtorrent so I'm not sure to understand this sentence

Maybe we could reduce the size of the moov atom? https://stackoverflow.com/questions/12617080/how-to-reduce-size-of-moov-atom-of-h-264-movies-to-improve-streaming-start-for-s#

ping @rigelk

[scanlime]

re queueing, I meant that due to the combination of the concurrent requests and the link's bandwidth limit, the time between submitting a request and finishing the last byte bas been increasing more than I'm used to seeing when things work correctly. Not yet sure if that's part of the problem.

Re reducing the moov atom size... I'm not sure how we could do that without splitting the video up into smaller pieces, but if that's possible I'm all ears :)

[Chocobozzz]

Unfortunately I don't think we can reduce the moov atom size. Fragmented mp4 may be a solution, but videostream does not support it: https://github.com/jhiesey/videostream/issues/20

[scanlime]

I'm super interested in the videostream internals, wonder if there's some way to start playing the video with partial data from the moov atom.. I'll read some code.

Another idea that comes to mind: it may be useful for multiple reasons to have a separate transcode that is both low-resolution and very low frame rate. This could be downloaded early (first even?) and used for thumbnails during loading and during seeking. This might be a way of achieving live thumbnails during seek, like YouTube has been supporting recently, also a feature that's quite handy for longer videos.

[rigelk]

@scanlime if you feel like hacking on videostream that's all the better! But it's a tough piece.

As for your second §, it's an interesting approach ; please discuss and document your idea in #537 that already covers the topic of thumbnails in the seekbar, as this a bit out of scope of the current issue :slightly_smiling_face:

[Booteille]

I can confirm this issue is related to the "auto" mode. The video (https://peertube.mastodon.host/videos/watch/0b04f13d-1e18-4f1d-814e-4979aa7c9c44) doesn't load or play consistently when I play it with auto resolution but does play normally when I select the 360p. I am on 3G mobile network.

[Chocobozzz]

Should be fixed by the new player. See https://github.com/Chocobozzz/PeerTube/issues/1237#issuecomment-462246728