RTCMultiConnection v3 Video Scalable Broadcast

[mistris]

@muaz-khan please provide example with Video Scalable Broadcast where RTCMultiConnection v3 is used.
Currently there is only https://rtcmulticonnection.herokuapp.com/demos/Video-Scalable-Broadcast.html example where RTCMultiConnection v2.2.2 is used.

This morning I tried locally the same example with RTCMultiConnection v3 and watchers can't see the video stream. Only initiator can see his own video.

[muaz-khan]

OK. I'll add a demo in the next commit. However #87 may take time (a week or two) to be fixed, because current scalable-broadcast architecture fails if any of the middle node leaves.

[mistris]

I rewrited Scalable-Broadcast.js architecture a little and just tested https://rtcmulticonnection.herokuapp.com/demos/Video-Scalable-Broadcast.html with RTCMultiConnection v3.
A is initiator and he sends video stream to B, C, D.
B forwards stream to E.
B disconnects, E rejoins to A.
The only problem is that B,C,D,E don't see the video. Only A sees his own video.

Waiting for your next commit with RTCMultiConnection v3 scalable video broadcasting demo 👍

[mistris]

@muaz-khan Can you please provide v3 demo before you start to fix #87?

[muaz-khan]

Here is a LIVE demo:

• https://rtcmulticonnection.herokuapp.com/demos/Scalable-Broadcast.html

[mistris]

@muaz-khan Thank you very much!
Now viewers are able to see the video stream. As I rewrited Scalable-Broadcast.js a little bit, now I'm able to rejoin (connect to first available broadcaster). But there is one problem - video is refreshed and full-screen is turned off.

1. Is it possible to use some kind of buffer for video for about 5 seconds while user is trying to reconnect with first available broadcaster? After that he could watch live stream video instead of buffer. Is it possible?
2. When user has lost his broadcaster and rejoins with other broadcaster (first available), full-screen is turned off. Is it possible to keep full-screen setting (on/off) after switching broadcaster?

Are you planning to fix these things yourself?
Thanks.

[mistris]

@muaz-khan waiting for your answers ℹ️

[muaz-khan]

We need to override onstreamended in the HTML file to prevent video removals.

We can use MediaStreamRecorder.js or RecordRTC to keep last 2-3 minutes recordings; and play recorded stream until new broadcaster joins.

BTW, yep, I'll fix #87 and similar issues soon, in 1-2 days.

I'll improve Scalable-Broadcast.js to make sure it works as expected. Currently last viewer is selected to relay video which seems not a good idea.

[mistris]

@muaz-khan Cool, then it will be ready on monday. I really appreciate your contribution! 👍

Can you please make a sample / demo, where any recorder is used to play recorded stream until new broadcaster joins?
Will you fix buffer (recorder) and full-screen things in next commit?
And what do I need to write in onstreamended to prevent video refreshing? If I just comment out

e.mediaElement.parentNode.removeChild(e.mediaElement);

it gives me black screen instead of video from the next broadcaster (how can I replace old video with the new one?)

[muaz-khan]

Recording support has been added in the recent commit: d79b5ff

Now onstream is not appending new video; instead it simply sets URL for existing video element.

Also, onstreamended tries to play recorded stream. Recorded stream is played in a loop until upper-node resumes the original stream.

ConcatenateBlob.js is used to concatenate all recordings; however it seems not working.

Chrome stable will merely record video tracks. Chrome Canary with chrome://flags/#enable-experimental-web-platform-features flags enabled will record both incoming audio and video into single file.

[mistris]

@muaz-khan Thank you very much! 👍 I just tested your recent commit on the latest Chrome (with enabled experimental web platform feature flags) and Firefox. It seems a good idea to change URL for existing video element.
I noticed that onstreamended tries to play recorded stream in a loop but there are some bugs which I will try to describe in a scenario I tested:

On Chrome (version: 48.0.2564.103 m):

1. A is initiator. B, C and D gets stream from A.
2. E gets stream from D.
3. D disconnects, E gets recorded stream in a loop. And at this moment A can't see his own video anymore (it is a bug. There was no such a bug in previous version). In this case A should see his own video and E should rejoin to B.

On Firefox (version: 44.0):

1. A is initiator. B, C and D gets stream from A.
2. E connects to D, but doesn't see the video. D at this moment sees message that he is forwarding stream to E.

P.S. Can you please fix these bugs? And when can we expect full working example / demo where:

• A is initiator.
• B, C and D gets stream from A.
• B, C and D are potential broadcasters who can forward the stream to new watchers.
• E joins and gets the stream from B (because at this moment B doesn't forward the stream to 3 other watchers) - this is Rejoining the same broadcast #87 where Scalable-Broadcast.js should be refactored to allow cases when middle node leaves.
• B disconnects so E rejoins to A (if A doesn't already forward video stream to 3 other watchers) or other broadcaster who has less than 3 watchers. When B disconnects, E sees recorded video from the same place where B disconnected (in my opinion 4-5 seconds recording should be enough).
• When E successfully rejoins to A, he sees live stream from A instead of recorded video (at this moment it would be very good if user couldn't notice that he is switching from recorded stream to live stream video).

[mistris]

@muaz-khan I'm looking forward to hear answers to my previous comment from you soon 👂 You are our only hope ❗ 😃

[maurodelazeri]

@muaz-khan Is there any way to turn in real time WebRTC into something like a url to HLS?
For example, 4 users doing an audio conference by WebRTC and transmit it with Icecast server for example? It will scaling really fast

[mistris]

@muaz-khan Hi! You did a great job here. Thank you! 👍
However there are still some bugs which should be fixed and you already know about 2 of them:

Known issues:

1. Sometimes it hangs the browser.
2. Also “Maximum call stack size exceeded” on server.

Other bugs which I noticed:

1. On Firefox all users connect to initiator instead of first available broadcaster
2. When nested nodes try to rejoin, they see the recorded stream in a loop (infinite) and that recorded stream is not switching to live video stream when rejoin is successful. Recorded stream is playing all the time in this case. To fix this bug:
2.1. recorded video stream must play from the place where user lost his broadcaster (so he will not notice that he is now watching recorded stream)
2.2. when rejoin is successful, recorded stream must be switched to live stream
3. In case when middle node leaves, only upper node should rejoin to first available broadcaster not everyone who lost his broadcaster. It would be more optimal and work faster (as you mentioned in muaz-khan/WebRTC-Experiment#2)

Can you please fix these bugs?

[mistris]

Also in browser console now there is an error:

To repeat it, just open https://rtcmulticonnection.herokuapp.com/demos/Scalable-Broadcast.html and start a video stream

[mistris]

@muaz-khan please let me know what do you think about both of my previous comments

[muaz-khan]

The image you attached in this commit is referring video.src=null so it is not a bug.

All these issues are in my todo list however I'll be able to try fixing them at next Wednesday.

[mistris]

Ok, waiting for your next commit 😃

[mistris]

I just noticed another bug:

1. A is initiator
2. B and C gets stream from A
3. D gets stream from B
4. D disconnects and B gets recorded stream in endless loop

[mistris]

Hey @muaz-khan! Did you fix something?

[jatinderwalia]

Hello Muaz,
i am very new to webrtc and rtcMulticonnection.
I am looking for an explanation to rtcMulticonnection architecture and what i am gettiing is leading me to pages which are straight jumping to practical tutorials.I am looking for some good articles which can help me understand what rtcmulticonnection does in theory ie architecturally.Would be grateful if you can refer any ghud article that explains rtcmulticonnection architecturally.
Thanks