Command line argument for changing HLS start media sequence number

[Canta]

This ticket is for a new functionality.

I would like to be able to set the initial "EXT-X-MEDIA-SEQUENCE" tag for HLS packaging by command line argument.

The use case this is related to is "graceful restarts for shaka packager live streams". Allow me to explain it:

I have many different live streams provided by third parties. I do stuff with the streams (transcoding, transrating, packaging, and so on), and then publish it. Shaka packager is part of my software pipeline for some streams.

I can't control the origin streams, as I don't control the origin enconders. I do what I can from my side to ensure resiliency, but there are limits for what I can do. Short version of the story: when there are problems with the origins (and there are several different scenarios for it), shaka packager stops and needs to be restarted. And, on restart, shaka packager starts the live stream packaging as a new one, and not a continuation from the previous one.

Most players stall in that situation: they refresh the playlist, they see no matching sequence number (nor discontinuity tag for the matter), and then don't play anymore.

So, working on LIVE HLS streams resiliency with focus on player compatibility, I believe the cleanest way is the ability to set the initial sequence number, with a forced discontinuity tag, at packager startup. I've modified shaka packager's code, done some experiments, and it's working great, so I bring this functionality for your consideration.

Please take a look at this code. There, you can see I've added an extra command line argument to shaka packager: hls_media_sequence_number. I use it this way:

--hls_media_sequence_number $(( $(date '+%s') / 6 ))

That '6' is my segment duration in seconds. What this does is: on next shaka packager start (which most likely will be an automatic restart because of some problem with the origin stream), the media sequence number will be necessarily greater than before, no matter how bigger was on last run, and actually continuous after a real stream gap, because previous shaka instance was also started with that parameter. Thus, the players reads the new generated playlist as an update of the previous one, and keep playing.
For this to work, this code also adds the discontinuity tag when any value of sequence number is forced by command line, as if it were actually a restart from a failure.

That's my use case. Other people may find it useful for other reasons.
Please let me know if you like the proposal. And, of course, if you find the code ok, you can also use it as you please.

Thanks, and hapy new year!.

[Canta]

Hi there.

I believe this ticket should have the "enhancement" tag.
If any of you shaka devs has the chance to take a look at this, please do, as I wouldn't want to mantain a fork just for a single command line argument.

Thanks!

[kqyang]

@Canta Sorry for the delay in response.

I can't control the origin streams, as I don't control the origin enconders. I do what I can from my side to ensure resiliency, but there are limits for what I can do. Short version of the story: when there are problems with the origins (and there are several different scenarios for it), shaka packager stops and needs to be restarted. And, on restart, shaka packager starts the live stream packaging as a new one, and not a continuation from the previous one.

Yes, that is a difficult problem. We had some thoughts on this. An idea we had was to persist the current states to a file then restore it later after restarts, but we had not found time and resource to implement it.

It is an interesting idea to keep the player happy by manipulating HLS media_sequence_number only. I do have a few questions on this though.

• When player restarts, the information of the previous generated segments are gone, i.e. the player list is empty. Do you do anything to merge the new playlist and the old playlist so the player can seek back? Or do you just accept it as a acceptable limitation?
• The discontinuity sequence number is not persisted, so it will be dropped to 0 after restart. Are players ok with this? What players are you using?

Other than that, your changes look good to me. You are welcomed to send a pull request to us!

[Canta]

Sorry for the delay in response.

It's cool! Thanks for taking a look to it.

When player restarts, the information of the previous generated segments are gone, i.e. the player list is empty. Do you do anything to merge the new playlist and the old playlist so the player can seek back? Or do you just accept it as a acceptable limitation?

I do nothing. I could, and was about to actually, but didn't.

My approach was going to be some croned bash alchemy working with the files found in the directory and automatically generating a second medialist with extra data added to shaka packager's one. It most likely would work, but preferred not get into that mess unless requested by real life needs (restarts should be a rare situation anyways, and if that's not the case then something else is going on and needs to be fixed instead of tolerated).

So, as you also clearly know, this restart issue is tricky, and I wanted to keep the use case simple: "just keep playing". Those live player stalls are my main enemy here. Therefore, If my changes don't break anything, I'm satisfied with this and consider it a start for a larger and more robust solution (like your status saving suggestion), with real life data and experience regarding the issue.

The discontinuity sequence number is not persisted, so it will be dropped to 0 after restart. Are players ok with this? What players are you using?

In my experience (and please know that I'm no expert at all), it's optional. It's important for synchronization between medialists with different discontinuities, but otherwise safe to ignore. I don't suffer from this loss, as the discontinuity involved in a restart is cross-rendition (they all restart). Also, when you don't include this tag, it's assumed to be zero, which is the case when a restart takes place. So, not a big problem for me. I don't know about other use cases.

I mostly test with different videojs+hlsjs players online, and shaka player from time to time (I use shaka player mainly for DASH, not HLS). But my main tests come from some native players for Apple OSs (IOS and OSX), as my streams implement FairPlay. I do not program those players (other teams do it), so I know little about their techs. Sorry. But I can tell you anyways that the restarts keeps on playing with this.

[kqyang]

@Canta Thanks for the thorough explanations. Are you planning to send a pull request with your changes?