HLS livestream problems

Problems with Unreal Media Server

HLS livestream problems

Postby nmargaritis » Fri Oct 26, 2018 1:31 pm

Hi there,

We are facing the following issues during broadcasting of HLS livestreams via unreal media server (v13). We deployed HLS with IIS as you suggest in your guides.

The first issue is that there is a mismatch between the requested .ts parts of a m3u8 playlist when you setup an hls livestream and how many parts are generated from umedia. It appears that if you set umedia to place 3 parts in a playlist it actually puts 2 and creates one of 0 bytes on disc. To overcome this issue we simply requested from umedia to include 4 .ts parts on an m3u8 playlist so that we get 3.

The second and most important issue is related with 404s while parts are requested form clients. Based on the nature of our application and deliverability concerns on mobile devices, our configuration is the following:

* 3 .ts parts of 2 seconds each. Each segment has a size of approx 100 KB.

Note that, concerning the stream source we are using the codecs (h264 profile baseline 3.0, aac) and settings as they are suggested by Apple. Our streams actually open on all IOS devices in about a second. Our player is flowplayer (7.2.7) and hlsjs. Now the problem that we face is that a lot of times clients report 404s errors while fetching .ts parts. This results in the streams starting late due to retries. We narrowed down this issue on umedia deleting the segments files earlier than they should have been removed. So when the clients request the files through IIS the files have already been deleted.

As an example, please consider the following usecase. Client joins with mobile network to view a livestream (not 4g). It takes the client about 1 second to fetch the m3u8 playlist and another second to fetch a part. If parts are advertised and are deleted every 2 seconds (as it happens now) some clients might end up with 404 errors.

We would like to know how can se setup unreal media server to delete the parts with a specified delay. We would like to delete the parts in about 10-15 seconds after they were last advertised on a playlist, so that clients with slow connections dont end up with 404 errors. We are aware that this will have an impact on the partition size for storing these segments, this is not an issue for us.

Please let us know if there is a setting on umedia for this, or a possible solution to this issue (maybe a fix from your site, an ENV variable or something).
This is a really important problem for us ATM and is killing our service.

Playlist sample:
#EXTM3U
#EXT-X-TARGETDURATION:2
#EXT-X-MEDIA-SEQUENCE:173635
#EXTINF:2,
xxx/streams/m3u8/flv001/segments/p-00173635
#EXTINF:2,
xxx/streams/m3u8/flv001/segments/p-00173636
#EXTINF:2,
xxx/streams/m3u8/flv001/segments/p-00173637
nmargaritis
 
Posts: 0
Joined: Thu Oct 25, 2018 1:43 pm

Re: HLS livestream problems

Postby admin » Fri Oct 26, 2018 2:17 pm

Hello,

Your HLS segmentation settings are very aggressive and geared for low latency, why do you need that?
You only have 3 .ts parts of 2 seconds each.
Of course, your clients need to be fast in order to view such an HLS without missing segments.

"it actually puts 2 and creates one of 0 bytes on disc" - you are mistaken. When the file gets created, of course it is 0 bytes, refresh your Windows explorer in several seconds.
"umedia deleting the segments files earlier than they should have been removed" - we never saw that or heard of that.
The .ts chunks are deleted when they are no longer in .m3u8 manifest. Normally a client receives a new .ts chunk right after that chunk starts appearing in the .m3u8 playlist. It will disappear from .m3u8 in 6 seconds in your case.
So if by that time a slow client still didn't get it, nothing will help - the client is simply lacking download bandwidth.

You can simply do 10 .ts files, 10 seconds each - these are actually the settings recommended by Apple. Then the chunk stays in .m3u8 for about 100 seconds.
You can also use adaptive HLS.
admin
Site Admin
 
Posts: 1021
Joined: Fri Aug 21, 2009 10:13 am

Re: HLS livestream problems

Postby nmargaritis » Mon Oct 29, 2018 4:16 am

Hi there, no it does not have to do with the Windows explorer. If you set umedia with settings of 4 .ts parts, you get 3 .ts parts advertised inside the .m3u8 playlist file and not 4. The playlist file I provided above was actually a showcase, so please give it a try and check out the m3u8 playlist contents. Also it appears that parts are not there for 6 seconds. It varies, based on our measurements we have seen parts being deleted for as soon as 4.5 seconds. This means that 404 errors are unavoidable if the playlist parts are deleted earlier than they should. (note that our keyframes are every 1 second)

To continue further the Apple documentation states chunks of 6 seconds, 10 seconds is a configuration of the past [reference: https://developer.apple.com/documentati ... le_devices] . However, since we want instant playback, we can not go with 10 seconds nor 6. It is a different usecase for apple tv content and a different usecase for live football, which is our area. He had 10 second chunks in the past, and you had to wait a lot of time on IOS devices before you could see video. With our current setup we have managed to have playback in 1-2 seconds on IOS. Please note that, IOS devices require to fully download and parse 1-2 segments before playback starts. The bigger the segment the bigger the waiting time.

Also there are industry leaders, that utilise the exact same settings on HLS for livestreaming similar content, that is live football.

I would suggest that you take some time to debug the number of chunks as well as how much time they are present before they are deleted. We were getting 404s even with the 10-second segments (our previous setup), this is not a new issue we experience, but it is a bigger problem now, since parts change more frequently and thus we have more 404s.

The only possible solution I see before you investigate these issues, is to increase the number of .ts parts to 6, so that they stay longer before they are deleted.

Looking forward to your reply. Nicolas.
nmargaritis
 
Posts: 0
Joined: Thu Oct 25, 2018 1:43 pm

Re: HLS livestream problems

Postby admin » Mon Oct 29, 2018 10:18 am

" If you set umedia with settings of 4 .ts parts, you get 3 .ts parts advertised inside the .m3u8 playlist file and not 4."
We have never seen it happening; never heard such a complaint from customers. Cannot reproduce it.
Seems like it's something specific to your live stream that you are converting to HLS.

"Also it appears that parts are not there for 6 seconds. It varies, based on our measurements we have seen parts being deleted for as soon as 4.5 seconds."
That can happen if your live stream comes irregularly, with fluctuating bitrate, and/or doesn't have a regular interval for key-frames.
What's very important in such a case is - when starting HLS, do you have a setting "Start new .ts files with key frames only...." checked? Uncheck that setting. That may solve your problems. Segments don't need to start with key-frames for most players, including iOS.

So yes, your solution is to keep the segment length 2-3 seconds, but increase the number of .ts segment to 6-10.
And also make sure your live stream comes stable and you have sufficient bandwidth to receive that live stream.
admin
Site Admin
 
Posts: 1021
Joined: Fri Aug 21, 2009 10:13 am


Return to Experience and troubleshooting

Who is online

Users browsing this forum: No registered users and 1 guest