WebRTC Merge Stream - useless ?

[Alex A]

Hi,

I have a conference type-app being built around the example from the conference.html - (antmedia latest 2.3.0 20210302_1431) and i received an em ail from antmedia listing an article about WebRTC MERGE and how useful it is.

After reading this article of yours (linked here) it states the following;

"Imagine a situation where you are in an online conference, and there are five guests. When a new guest wants to watch (not participate) this conference, the number of total connections increases by five since every member of the conference needs to send their stream to the new guest."

Obviously to explain that a single-composite stream composed of everyones stream would be much more efficient if sent from the server. Okay, UNDERSTOOD.

BUT - and here is the Problem: ALL my tests show that first paragraph is not true! - literally false... because I have tested with 6 participants and can easily attach to the antmedia server with an unlimited (except for bandwidth/cpu/ram of server) clients to watch any of those published feeds without affecting ANY of their broadcast bandwidths.

I did this test like this;

- participant 1: linux machine running conference.html to join and BMON in the background to watch outgoing traffic ~35KiB)

- participant 2: linux machine running conference.html to join and BMON in the background to watch outgoing traffic ~35KiB)

... same for all.

Then whilst watching each of those outbound bandwidth usage (~35KiB each) I then attached a bunch of 'viewers' to the streams existing on Antmedia - and there was ZERO change to ANY of those publishers.

So the premise of this article about WebRTC MERGE seems completely false - as the stated 'conference.html' example as mentioned in the article specifically does NOT add a bandwidth burden to each participant for additional 'viewers' or 'spectators'.

Can you explain what this is about ? why would an article you just published yesterday be so contrary and hence confusing.

Thanks!

Alex.

[Selim Emre]

Hi Alex,

Thank you for the great feedback!

Can you explain what this is about ? why would an article you just published yesterday be so contrary and hence confusing.

Our default publisher bitrate parameter is 900kbps. As I saw your outgoing bandwidth traffic is a little bit low. It may be related to your bandwidth parameter. Are you sure your streams are in conference room publishing/watching properly?

Btw, I will test this issue with my test environment for you.

Best Regards,

Selim

[Alex A]

Hi,

Yes I reduced the bitrate only but otherwise it is the same structure as conference.html - the point is not the bandwidth individually, the point is the bandwidth does not increase with each 'viewer' attached - so the premise in the article "every member of the conference needs to send their stream to the new guest" is not true - this is only true in a peer-to-peer conference however peer-to-host and then host-to-viewer is not true.

Anyway, it is strange, it is as if this article was written regarding the peer-to-peer connection system of webrtc but not about antmedia.

Thanks

Alex.

[Selim Emre]

Hi Alex,

Have a good day. 

Thanks for the details. I think @Cem wrote this article for a peer-to-peer conference situation. I will discuss this issue with @Cem

Best Regards,

Selim

[Alex A]

Hi Selime,

Yes it makes perfect sense and is completely true in a P-2-P context - it is just because the article talks specifically about the 'conference.html' example in Antmedia makes it confusing, because it is not true for this example.

I was not just being pedantic, the reason it matters for us is because this is the precise use-case for us with Antmedia so we wanted to make sure we had a complete and correct understanding.

Thanks for confirming! 

Alex.