How the media request range works?

user_6521116 0
Viewed 177

I've video in the html with video tag like <video src='xxxx.mp4'>. But sometimes the video loading is very slow.

I check the media request and find it try to load a 1MB data at the first video request. The request header is as below, but with no range settings.

And some video's first request size is very small, then it can show the first frame quickly. How the video media request works, can I influence the request size each time?

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Connection: keep-alive
Cookie: UM_distinctid=17e6bd4dd5c30-0f869b25cdf7158-4c3e207f-151800-17e6bd4dd5d5ce
Host: concert-cdn.jzurl.cn
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
TE: trailers
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:98.0) Gecko/20100101 Firefox/98.0
video-streaming media video html
1 Answers

If you are using just the video tag then the particular browser implements the logic to decide what size ranges to request. Some browsers actually request the entire file first, then abort that request and follow with individual range requests. You will also see requests from a browser with no end range as it 'looks' through the file - the logic again seems to be that a request can simply be cancelled if the rest of the data is not needed.

If you are using a Javascript player, like video.js etc, the player can in theory control this type of thing, but in practice for mp4 files, I think, many players just leverage the browsers HTML Video tag functionality anyway.

Focusing on what you are trying to achieve, there are a couple of things you can do to speed initial playback.

Firstly checking your server accepts range requests which it sounds like you have already done.

Next, assuming you are streaming an mp4 file, make sure the metadata is at the start - the 'MooV' atom as it known. There are several tools that will allow you make this change including ffmpeg:

The mov/mp4/ismv muxer supports fragmentation. Normally, a MOV/MP4 file has all the metadata about all packets stored in one location (written at the end of the file, it can be moved to the start for better playback by adding faststart to the movflags, or using the qt-faststart tool). A fragmented file consists of a number of fragments, where packets and metadata about these packets are stored together. Writing a fragmented file has the advantage that the file is decodable even if the writing is interrupted (while a normal MOV/MP4 is undecodable if it is not properly finished), and it requires less memory when writing very long files (since writing normal MOV/MP4 files stores info about every single packet in memory until the file is closed). The downside is that it is less compatible with other applications.

If the above does not address your needs then you may want to look at using an Adaptive Bit Rate streaming protocol. Nearly all major streaming services use this approach, but it does require more work on the server side and generally a special streaming packager server, although there are open source ones available (e.g. https://github.com/shaka-project/shaka-packager).

ABR creates multiple different bandwidth version of the video and breaks each into equally time sized chunks, e.g. 2 second chunks. The client device or player downloads the video one chunk at a time and selects the next chunk from the bit rate most appropriate to the current network conditions. It can choose a low bandwidth chunk to allow a quick start and you will often see this on commercial streaming services where the video quality is less at start up and then improves over time as high bandwidth chunks are requested subsequently.

More info here: https://stackoverflow.com/a/42365034/334402

user_3344020
Related