当客户请求一条流时，media-server会在边缘进行即时的hls切片，把从帧缓冲队列中拿到的音视频数据封装成ts格式，并返回给客户。
对于m3u8的请求，传统的做法是播放器发送请求给服务器，服务器接收到请求后，读取目前最新的已切好片的ts文件序列号，例如，当前的切片过程进行到了切片10，那么返回的http内容是第8，第9或第10个ts文件。在这种情况下，一个影响客户体验的问题是它无法为每一个用户提供一个定制的索引文件。例如，所有用户请求m3u8时，会返回相同的已切好片的ts文件，此时会产生一个较大的播放延迟。
面对上述提出的问题，media-server用如下方式解决问题：
- 用两层m3u8索引文件来为用户定制ts文件。客户端首先会发送一个m3u8请求给服务器，此时服务器收到该请求后会为请求生成一个用户标识（userID），并生成一个dynamic.m3u8文件，将下一次请求的URL地址放在这个dynamic.m3u8文件中，然后将刚刚生成的用户标识放在这个URL的请求字符串中返还给客户端，同时记录下该用户请求的状态。
- 当客户端收到回复后，从回复中拿到URL，并请求这个URL，等待服务器的返回。
- 当服务器收到dynamic m3u8的请求后，会产生真正的ts切片文件列表给客户端，此时服务器会根据请求里的用户标识来专门为客户生成ts切片序列。
- 服务器采用了超低延迟技术。客户端接收到ts切片文件列表后，接着会请求ts文件。传统的实现会返回已产生的ts文件，这样会产生很大的延迟。本质上来说，只需要在客户端请求ts文件时，服务器及时返回就可以了。于是服务器在实现上可以将“还未产生的ts文件列表”发送给客户端，当客户端真正来请求时，如果该ts文件还未产生或正在产生，该TCP连接就会处于pending的状态，直到ts文件完全传输完成。
- 在实现上，media-server会产生3个“未来”的切片，而第一个切片是当下刚刚生成的，这样就可以实现类似于rtmp/flv的延迟。如果当下的ts切片是当下正在生成的，那么客户端的首播延迟将非常高（即需要等待一个ts切片长度的时间，如果是1秒钟，那么最长就会等待一秒）。所以一种更好的方式是返回当下之前的最后一个关键帧所在的ts切片。优点是客户端可以秒开，缺点是最少会产生一个ts文件长度的延迟，可以得出配置的ts长度越短延迟越小。在线上系统中，可以将ts文件长度设置为一秒，于是hls直播的延迟仅比rtmp/flv慢一秒左右，达到了业界的最小的hls延迟时间。