Add delay to player

[Azhar Ali]

Hi,
We stream single room using chatrooms. It's audio only.
We want to give out free version to our users but with one min delay. Is that possible?
So some users gets audio live and some gets with a min delay

Thanks for the help

 

[Max]

Good day.
You can not add any delay to realtime stream unless channel bandwith is too bad.
But you can for example stop playing the stream for free users after some time and display some banner. This should be done on client browser side.
Another way is to record live stream with 1 minute rotation

record_rotation=60

then copy recording files with hook script to WCS_HOME/media folder and play those recordings as VOD to free users. Again, you should do some work on frontend to play recordings continuously, one by one.

 

[Azhar Ali]

Hi Max,

Would there any proper solution to allow a delay setting for some users? Its quite an important requirement for us and if this can be added in the roadmap that would be great.

Your suggested recording solution seems, it might work for some but just doesn't seem robust enough to rely on it especially with autoplay policy of browsers blocking.

Anything else you can think of to delay stream to set of users by 3-4 of seconds?
Anything around connect them to different node which can have a delay?

 

[Max]

Switching to TCP transport may delay desired 3-4 seconds.
You can try on the Media Devices example.

 

[Azhar Ali]

Hi Max,

We tried switching to TCP and it didn't make much difference. Latency was still sub-second.

Could something like this work:
- We stream over WebRTC and also to WCS rtmp URL (same server)
- then can we force the player to play using webrtc but using the source stream from RTMP.
- Would that add few seconds delay?
- Would the above can work if we host another WCS server and stream to RTMP of that server and than based on user subscription play from one or the other?

Not sure if thats possible?

We have developed our own player using the Web SDK so can't use embed player.

 

[Max]

Good day.

- then can we force the player to play using webrtc but using the source stream from RTMP.
- Would that add few seconds delay?

Yes, if you publish RTMP stream and play it as WebRTC, it should add some delay.

- Would the above can work if we host another WCS server and stream to RTMP of that server and than based on user subscription play from one or the other?

Yes, it should work.

 

[Azhar Ali]

session.createStream({
        name: streamId,
        display: document.getElementById('media-publisher'),
        record: false,
        constraints: constraints,
        rtmpUrl: YTRTMPURL
    })....

How do you force to play rtmp stream? In the above code, we just pass the streamName and if the server is the same, would it not play webrtc to webrtc? Its the same server which is publishing via WebRTC to WebRTC + RTMP but in some cases we want to do WebRTC - > WebRTC and for purpose of delay play WebRTC - > RTMP.

Or is that only possible with another WCS server?

 

[Max]

We stream over WebRTC and also to WCS rtmp URL (same server)

If it means that the WebRTC stream is republished as RTMP, then there are two different streams with different names. So, which stream will be played would depend on the name specified for playback.

 

[Azhar Ali]

How can I find the name of rtmp stream? So that we can play via webrtc

 

[Max]

By default, republished RTMP stream is named rtmp_<source stream name>. The prefix ("rtmp_") can be changed using setting rtmp_transponder_stream_name_prefix in flashphoner.properties.

 

[Azhar Ali]

Hi Max,

I checked the flashphoner.properties and its setup as

rtmp_transponder_stream_name_prefix =rtmp_
rtmp_transponder_full_url=true

Testing demo.flashphoner.com
Using the WebRTc as RTMp example, streamed with the streamName xyz
Tried to play the stream as rtmp_xyz using the player example.
Works fine.

Testing on server
Using the WebRTc as RTMp example, streamed with the streamName xyz
Tried to play the stream as rtmp_xyz using the player example.
Stream does not play.
Tried to play again using full url as the stream Name rtmp://wcs-server:1935/live/xyz
Works fine.


So my question is, any reason why its different on how it works on demo and our server?
Should I not expect some delay playing rtmp using webrtc? In all the examples where it worked, there was no delay.

We running out of options to add the delay to our free service and would greatly appreciate some input


Have you got any plans to support playoutDelayHint

Hint attribute in WebRTC to influence underlying audio/video buffering

In WebRTC it is currently up to the User Agent to decide how much or little audio/video received on the network to buffer before playout. More buffering increases the likelihood of smooth playout but increases the playout delay. The User Agent makes the decision based on network conditions...

discourse.wicg.io

 

[Max]

So my question is, any reason why its different on how it works on demo and our server?

On demo.flashphoner.com, the default settings are used:

rtmp_transponder_stream_name_prefix =rtmp_
rtmp_transponder_full_url=false

When you enable rtmp_transponder_full_url=true, the stream name is taken from publishing URL as is. That's the difference.

Should I not expect some delay playing rtmp using webrtc? In all the examples where it worked, there was no delay.

If you're streaming audio only (that's your case, right?), you can try to publish RTMP stream from OBS Studio or another streaming application that can add delay to audio.
So publisher should use 2 different microphones, OBS or another RTMP streamer to publish RTMP with delay and browser to publish WebRTC without delay. In this case, additional WebRTC as RTMP republishing is not needed.

 

[Max]

Good day.

Have you got any plans to support playoutDelayHint

We implemented playoutDelayHint support in WebSDK build 0.5.28.2753.142 which shipped with WCS build 5.2.708. Please see the doc here.
Unfortunately, this does not work for audio tracks in streams and for audio only streams.
We raised a new ticket WCS-2816 to add a WebRTC bufferization settings on server side to work for any stream in any browser.

 

[Azhar Ali]

thanks Max, any timeline for the WCS-2816?

 

[Max]

Good day.
We working on ticket WCS-2816 and let you know here. Please be patient.

 

[Azhar Ali]

Thanks will wait.
Would you be able to choose from client side to add delay to the stream based on user subscription?..That would be ideal.

 

[Max]

Would you be able to choose from client side to add delay to the stream based on user subscription?..That would be ideal.

We'll think about it.
Please note that all the subscribes of delayed stream will receive the delay due to server side buffering. So you will probably need to publish two streams, one for delayed playback and one for immediate.

 

[Azhar Ali]

That is what we are doing currently.. publishing delayed using OBS where there is an option to add a delay.
Ideal would have been to have this working with single stream as upload speeds are limited and streaming twice affects the general performance of both streams.
Or have an option to auto republish on the server level with buffer

 

[Max]

Ideal would have been to have this working with single stream as upload speeds are limited and streaming twice affects the general performance of both streams.
Or have an option to auto republish on the server level with buffer

This can be reached with republishing a stream to localhost as RTMP

POST /rest-api/push/startup HTTP/1.1
Host: 192.168.1.101:8081
Content-Type: application/json
 
{
    "streamName": "original_stream",
    "rtmpUrl":"rtmp://localhost:1935/live"
}

and playing stream republished rtmp_original_stream with buffering via WebRTC.
Fuithermore, in the latest builds you can use RTMP bufferization feature in this case. For example, setting the options

rtmp_out_buffer_enabled=true
rtmp_out_buffer_start_size=5000
rtmp_out_buffer_initial_size=5000

should give a latency near 10 seconds playing stream republished via WebRTC. This works both for video and audio streams.
Please try it, if this works for you, maybe you wouldn't need additional WebRTC bufferization.
For example, you can set the following options

rtmp_transponder_full_url=true
rtmp_out_buffer_enabled=true
rtmp_out_buffer_start_size=5000
rtmp_out_buffer_initial_size=5000
[CODE]
and republish the strea with a given name, for example
[CODE]
POST /rest-api/push/startup HTTP/1.1
Host: 192.168.1.101:8081
Content-Type: application/json
 
{
    "streamName": "paid_stream",
    "rtmpUrl":"rtmp://localhost:1935/live/free_stream"
}

and play free_stream for free customers via WebRTC with 10 seconds latency, and paid_stream for paid customers without latency

 

[Azhar Ali]

Thats interesting, will def give it a go..seems like most solid solution. I take it if I adjust the buffer parameters I can add a delay of 1min?
And rmtp should work with cdn setup we have?