[jitsi-dev] Does JVB support multiple unrelated source streams on a single video channel?


#1

We are trying to test JVB but have not embraced simulcast yet. In the past
(say, as of last August) we were able to send multiple unrelated streams on
a single video channel. With the latest code, we can still send multiple
streams in a video channel, but the FIR logic doesn't get triggered
properly in all cases.

What we see happening when a user joins an existing conference is that one
of the video streams on a channel starts immediately, while another stream
on that channel languishes until a keyframe comes through.

So it seems that the VideoChannel/BitrateController implementation assumes
that there is only one video stream per endpoint. Is this understanding
correct?

- Chris Young


#2

George can probably confirm, but it wouldn't surprise me if your
understanding is correct...In general I think there are assumptions of only
a single video stream so multiple videos is a use case that likely doesn't
get tested :confused: If so we should get a bug open for this, especially since it
was working before.

···

On Mon, May 15, 2017 at 11:23 AM, Chris Young <chris.young@sococo.com> wrote:

We are trying to test JVB but have not embraced simulcast yet. In the
past (say, as of last August) we were able to send multiple unrelated
streams on a single video channel. With the latest code, we can still send
multiple streams in a video channel, but the FIR logic doesn't get
triggered properly in all cases.

What we see happening when a user joins an existing conference is that one
of the video streams on a channel starts immediately, while another stream
on that channel languishes until a keyframe comes through.

So it seems that the VideoChannel/BitrateController implementation assumes
that there is only one video stream per endpoint. Is this understanding
correct?

- Chris Young

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#3

Brian is right, the adaptivity rewrite imposed this limitation, however we’ve recently implemented multi-track bitrate allocation, so this limitation is removed.

···

On Jun 12, 2017, at 4:29 PM, Brian Baldino <brian@jitsi.org> wrote:

George can probably confirm, but it wouldn't surprise me if your understanding is correct...In general I think there are assumptions of only a single video stream so multiple videos is a use case that likely doesn't get tested :confused: If so we should get a bug open for this, especially since it was working before.

On Mon, May 15, 2017 at 11:23 AM, Chris Young <chris.young@sococo.com <mailto:chris.young@sococo.com>> wrote:
We are trying to test JVB but have not embraced simulcast yet. In the past (say, as of last August) we were able to send multiple unrelated streams on a single video channel. With the latest code, we can still send multiple streams in a video channel, but the FIR logic doesn't get triggered properly in all cases.

What we see happening when a user joins an existing conference is that one of the video streams on a channel starts immediately, while another stream on that channel languishes until a keyframe comes through.

So it seems that the VideoChannel/BitrateController implementation assumes that there is only one video stream per endpoint. Is this understanding correct?

- Chris Young

_______________________________________________
dev mailing list
dev@jitsi.org <mailto:dev@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev