Stream DVR

[naanlizard]

Is your feature request related to a problem? Please describe. With our current streaming server, nginx-rtmp, we can provide to viewers an arbitrary length of stream history they can seek back through. This is the only issue preventing us from using OvenMediaEngine exclusively

Describe the solution you'd like A configurable playlist length for HLS, Dash, LL-Dash (if possible?) that will allow players to seek backwards in time through the stream.

Describe alternatives you've considered We are currently planning to switch from stream input->nginx-rtmp->OME to input->OME->nginx-rtmp and only use nginx-rtmp for the long playlist length seeking, but this is not a clean solution of course

[joschahenningsen]

I'm currently considering a similar switch from nginx-rtmp + wowza to ome and this feature would be essential. @naanlizard if you are successful with the mentioned workaround feel free to share some details about it :)

[getroot]

I'll add this feature to our backlog. Thanks for the suggestion. However, since there are many higher-priority tasks, it will take quite a bit of time.

[naanlizard]

Can we help prioritize this in any way? Offer a bounty, do some prep work, anything? I don't have any non-webdev programmers on staff unfortunately 😅

[joschahenningsen]

We might be able to provide a developer to work on this a few hours/week (ping @alexanderstephan) but might need some input as to how to get started with this, would that be of any help @getroot?

[getroot]

@joschahenningsen

It is of course very helpful for all of us. I'm completely focused on supporting HTTP/2 and LLHLS these days. It's a very big challenge and I'm using it almost all of my time. So I don't have time to look at other features for the time being.

A user's request for HLS starts from the function below.

https://github.com/AirenSoft/OvenMediaEngine/blob/a2f6451bfc3bec33760f8a9c888d75d507911cf0/src/projects/publishers/segment/hls/hls_stream_server.cpp#L14

Currently, HLS segments are stored as many as segment count * 2. This should probably be increased enough according to the new DVR settings in Server.xml. Memory may be a concern, so you may need the ability to save and load as a file.

https://github.com/AirenSoft/OvenMediaEngine/blob/fdce9098e7b55c2e35df4b5e6d73bc08108ef319/src/projects/publishers/segment/hls/hls_packetizer.cpp#L41

A default playlist.m3u8 is created automatically. However, DVR will have to create and provide playlist.m3u8 on the fly according to user's request.

https://github.com/AirenSoft/OvenMediaEngine/blob/fdce9098e7b55c2e35df4b5e6d73bc08108ef319/src/projects/publishers/segment/hls/hls_packetizer.cpp#L390

[naanlizard]

In nginx rtmp it simply offers one playlist I believe, which simply grows as the stream goes on up to the DVR time limit. Probably that's easier to implement than custom requests

Definitely storing everything in memory is infeasible for at least our use case though storing the most recent segments probably makes sense

[naanlizard]

An aside that I'm not sure where to put, how is the http2 upgrade going @getroot? What will the advantages be when it is released?

And with the recent got book changes, are airensoft planning a commercial version of OME?

[getroot]

@naanlizard If the player supports it, we can also develop the DVR in a way that provides all segments. However, making the playlist too large can be a major drawback. This is a specification to consider when implementing a DVR. (Because HLS Live DVR does not have standard specifications)

HTTP/2 is a required protocol for LLHLS (Apple compliant). So I'm developing it, and HTTP/2 is almost done with implementation now. (You can check it by referring to the recent commit log)

We didn't intend to create a commercial version of OME, but we had no choice but to plan an Enterprise version as we considered introducing commercial encoders (for H.264, H.265) to OME. x264 has licensing issues, and OpenH264 has quality issues. For commercial encoders, we have to pay for it and we have to manage the number of licenses, so we have no choice but to prepare an Enterprise version. We thought this was a must for WebRTC/LLHLS ABR, and it was also a request from our big customers.

[naanlizard]

Does llhls require encoding or is that only for ABR?

I mentioned nginx-rtmp since several of us have been using it it seems. Worth looking at how they and videjs player deal with his DVR.

[getroot]

Same as HLS, except that it is low-latency. If you don't need ABR, you don't need encoding. Of course, as with Legacy HLS, this is sometimes necessary for codec compatibility (e.g. when VP8 video is input through a WebRTC Provider).

[naanlizard]

@joschahenningsen are you moving forward with work on this? One of our devs could probably help, but we should get in touch to not duplicate work

[naanlizard]

Also apologies I forgot to tell you @joschahenningsen - OME->nginx-rtmp seems unreliable, streams played via nginx-rtmp/HLS buffer reliably after several minutes.

We may try forwarding via ffmpeg to test if OME forwarding is the problem or not, since OME/HLS streams (without DVR) seem reliable

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[joschahenningsen]

bump. @naanlizard sorry for the late reply. We are not actively working on this currently and will announce it here if we get to it. So feel free to work on this if you wish :)

Also I've seen that HLS has been deprecated now. So it would probably only make sense to implement it for LLHLS?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[getroot]

This feature has been released. https://github.com/AirenSoft/OvenMediaEngine/issues/982