[jitsi-dev] MediaStream Track is muted - REST interface


#1

So I have made some changes to the bridge so that when a stream is added it sends out the SSRC via the datachannel to all of the attached clients. It isn't very clever at the moment, but I wish to get the video stream to work before improving it.

I then respond in the client to the new SSRC by creating a new SDP with the SSRC in it and set that as the new remote description. I then get a new MediaTrackStream the details of which follow. It is "enabled", but it is also "muted" and its ready state is "muted". At least the element on the HTML page changes from white to black which means something is happening.

The Chrome Logs say: INFORMATION 14668 2140 14:07:07-415 0 OnLoadUpdate 1, is_screencast: false

Can anyone suggest what I might do to make it play. Chrome is now creating a sink for the specific SSRC.

MediaStreamTrackEvent
bubbles: false
cancelBubble: false
cancelable: false
composed: false
currentTarget: MediaStream
defaultPrevented: false
eventPhase: 0
path: Array[0]
returnValue: true
srcElement: MediaStream
active: trueid: "mixedmslabel"
onactive: null
onaddtrack: gotNewRemoteTrack(event)
oninactive: null
onremovetrack: null
__proto__: MediaStreamtarget: MediaStream
timeStamp: 24310.24
track: MediaStreamTrack
enabled: true
id: "mixedlabelvideo0"
kind: "video"
label: "mixedlabelvideo0"
muted: trueonended: null
onmute: nullonunmute: null
readyState: "muted"
remote:
true__proto__: MediaStream
Tracktype: "addtrack"__proto__: MediaStreamTrackEvent


#2

Further on this I have discovered that the mediastreamtrack is only muted after it is attached to a video element (Which can be a constraint problem). Looking at the stream itself it appears that a small number of packets of data (about 24 I think) are streamed to the client before it stops (probably because the client has not responded asking for more, but I don't know that much about the control channel).

···

On 26/01/2017 15:09, John Hemming wrote:

So I have made some changes to the bridge so that when a stream is added it sends out the SSRC via the datachannel to all of the attached clients. It isn't very clever at the moment, but I wish to get the video stream to work before improving it.

I then respond in the client to the new SSRC by creating a new SDP with the SSRC in it and set that as the new remote description. I then get a new MediaTrackStream the details of which follow. It is "enabled", but it is also "muted" and its ready state is "muted". At least the element on the HTML page changes from white to black which means something is happening.

The Chrome Logs say: INFORMATION 14668 2140 14:07:07-415 0 OnLoadUpdate 1, is_screencast: false

Can anyone suggest what I might do to make it play. Chrome is now creating a sink for the specific SSRC.

MediaStreamTrackEvent
bubbles: false
cancelBubble: false
cancelable: false
composed: false
currentTarget: MediaStream
defaultPrevented: false
eventPhase: 0
path: Array[0]
returnValue: true
srcElement: MediaStream
active: trueid: "mixedmslabel"
onactive: null
onaddtrack: gotNewRemoteTrack(event)
oninactive: null
onremovetrack: null
__proto__: MediaStreamtarget: MediaStream
timeStamp: 24310.24
track: MediaStreamTrack
enabled: true
id: "mixedlabelvideo0"
kind: "video"
label: "mixedlabelvideo0"
muted: trueonended: null
onmute: nullonunmute: null
readyState: "muted"
remote:
true__proto__: MediaStream
Tracktype: "addtrack"__proto__: MediaStreamTrackEvent

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


#3

You may be running into the following: In order to work around a bug in Chrome, when the connection is initially established, jitsi-videobridge will send a certain amount of "black" video frames to the receiver. If the sender sends no video, these will be the only packets the receiver gets, and since they just encode a completely black image, it will freeze in black. See the LipSyncHack class in the bridge.

Regards,
Boris

···

On 26/01/2017 14:11, John Hemming wrote:

Further on this I have discovered that the mediastreamtrack is only
muted after it is attached to a video element (Which can be a constraint
problem). Looking at the stream itself it appears that a small number
of packets of data (about 24 I think) are streamed to the client before
it stops (probably because the client has not responded asking for more,
but I don't know that much about the control channel).


#4

I have been looking further at the issue of RR reports not being received by chrome. These are not received from the videobridge. Doing a bit of logging it appears that RR reports are sent for both audio and video, but the video has a zero number of reports in the message whereas audio has one report.

It strikes me that the videobridge thinks that the video stream from chrome is muted when it isn't. I have looked at the stream in webrtc-internals and it is definitely sending a lot although of course one cannot be certain what it is sending.

As I understand it if the VB thinks that the video to the VB is muted it won't sent anything back to the chrome clients.

The question, of course, is why the VB thinks the video is muted.

···

On 26/01/2017 21:43, Boris Grozev wrote:

On 26/01/2017 14:11, John Hemming wrote:

Further on this I have discovered that the mediastreamtrack is only
muted after it is attached to a video element (Which can be a constraint
problem). Looking at the stream itself it appears that a small number
of packets of data (about 24 I think) are streamed to the client before
it stops (probably because the client has not responded asking for more,
but I don't know that much about the control channel).

You may be running into the following: In order to work around a bug in Chrome, when the connection is initially established, jitsi-videobridge will send a certain amount of "black" video frames to the receiver. If the sender sends no video, these will be the only packets the receiver gets, and since they just encode a completely black image, it will freeze in black. See the LipSyncHack class in the bridge.

Regards,
Boris

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


#5

I have written something to look at the mediastream stats for the live rtpchannels. It confirms what I thought:

org.jitsi.videobridge.AudioChannel Endpoint: 24b26b0aa Id:1fd3478442b438fa cb-id:24b26b0 sources localinitial=3473334870 remote=3018863852 and =3018863852CN:User@JAMH-I7Send Stream Count 1CN:User@JAMH-I7ssrc: 3473334870Bytes rec 458249Bytes sent 104921Pkts recd 4610Pkts sent 4553 12:40:52 12:40:52
videochannels:1
org.jitsi.videobridge.VideoChannel Endpoint: 24b26b0aa Id:97ced0637812c9ff cb-id:24b26b0 sources localinitial=753397753 remote=4019089026 and =4019089026CN:User@JAMH-I7Send Stream Count 0Bytes rec 10280Bytes sent 160Pkts recd 202Pkts sent 10 12:40:52 12:40:52

There are far fewer packets being recieved on the video channel when you would ahve though there would eb a lot more data.

Clearly the bridge thinks the video channel is muted coming in. Hence it is not surprising it is not sending much out and chrome thinks it is muted (because it is).

Can anyone please give me a hint where to look as to the test of muting of a channel in?

···

On 26/01/2017 21:43, Boris Grozev wrote:

On 26/01/2017 14:11, John Hemming wrote:

Further on this I have discovered that the mediastreamtrack is only
muted after it is attached to a video element (Which can be a constraint
problem). Looking at the stream itself it appears that a small number
of packets of data (about 24 I think) are streamed to the client before
it stops (probably because the client has not responded asking for more,
but I don't know that much about the control channel).

You may be running into the following: In order to work around a bug in Chrome, when the connection is initially established, jitsi-videobridge will send a certain amount of "black" video frames to the receiver. If the sender sends no video, these will be the only packets the receiver gets, and since they just encode a completely black image, it will freeze in black. See the LipSyncHack class in the bridge.

Regards,
Boris

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


#6

I have run this with three conference members and it is clear that the blockage is in the videobridge on the video/translator process

  Status

36d7330c-de0d-4014-835a-cdd03a49d50a number of conferences 1 id:93cdd650727804a2
audiochannels:3
org.jitsi.videobridge.AudioChannel Endpoint: 174536eaa Id:749d161c5c6d12da cb-id:174536e sources localinitial=1477420153 remote=3075206616 and =3075206616CN:User@JAMH-I7Send Stream Count 1CN:User@JAMH-I7ssrc: 1477420153 Bytes rec 131029 Bytes sent 142252 Pkts recd 1330 Pkts sent 1317 13:23:44 13:23:44
org.jitsi.videobridge.AudioChannel Endpoint: 2454de2aa Id:3972435979ad96b7 cb-id:2454de2 sources localinitial=4011915569 remote=1522868756 and =1522868756CN:User@JAMH-I7Send Stream Count 1CN:User@JAMH-I7ssrc: 4011915569 Bytes rec 112022 Bytes sent 121915 Pkts recd 1131 Pkts sent 1120 13:23:44 13:23:44
org.jitsi.videobridge.AudioChannel Endpoint: 11ebe98aa Id:aa9efceb314cceb2 cb-id:11ebe98 sources localinitial=3332472856 remote=2265260733 and =2265260733CN:User@JAMH-I7Send Stream Count 1CN:User@JAMH-I7ssrc: 3332472856 Bytes rec 151316 Bytes sent 148041 Pkts recd 1536 Pkts sent 1510 13:23:44 13:23:44
videochannels:3
org.jitsi.videobridge.VideoChannel Endpoint: 11ebe98aa Id:f0d20b684eded20d cb-id:11ebe98 sources localinitial=4290476336 remote=3117055007 and =3117055007CN:User@JAMH-I7Send Stream Count 0 Bytes rec 6656 Bytes sent 11796 Pkts recd 109 Pkts sent 94 13:23:44 13:23:44
Send to endpoints:174536eaa 2454de2aa
org.jitsi.videobridge.VideoChannel Endpoint: 2454de2aa Id:343c9a472b4621cb cb-id:2454de2 sources localinitial=4290476336 remote=1463524525 and =1463524525CN:User@JAMH-I7Send Stream Count 0 Bytes rec 5984 Bytes sent 2440 Pkts recd 85 Pkts sent 44 13:23:44 13:23:44
Send to endpoints:11ebe98aa 174536eaa
org.jitsi.videobridge.VideoChannel Endpoint: 174536eaa Id:9a42c7a544e834f6 cb-id:174536e sources localinitial=4290476336 remote=231756807 and =231756807CN:User@JAMH-I7Send Stream Count 0 Bytes rec 6396 Bytes sent 7256 Pkts recd 92 Pkts sent 70 13:23:44 13:23:44
Send to endpoints:11ebe98aa 2454de2aa
datachannels:3
org.jitsi.videobridge.SctpConnection Endpoint: 174536eaa Id:b0cb8cd05d7bf109 cb-id:174536e 13:23:33 13:23:42
org.jitsi.videobridge.SctpConnection Endpoint: 2454de2aa Id:99568286e81e3e3e cb-id:2454de2 13:23:33 13:23:43
org.jitsi.videobridge.SctpConnection Endpoint: 11ebe98aa Id:cba91b8844aa7cef cb-id:11ebe98 13:23:33 13:23:43
List cname source map
1522868756:FNGITvOpUftW1KKb
3075206616:LXoagZ3Q7x2gwXJH
3117055007:Hy+zpBIMuhvbEOTI
1463524525:FNGITvOpUftW1KKb
231756807:LXoagZ3Q7x2gwXJH
2265260733:Hy+zpBIMuhvbEOTI

···

On 31/01/2017 12:43, John Hemming wrote:

I have written something to look at the mediastream stats for the live rtpchannels. It confirms what I thought:

org.jitsi.videobridge.AudioChannel Endpoint: 24b26b0aa Id:1fd3478442b438fa cb-id:24b26b0 sources localinitial=3473334870 remote=3018863852 and =3018863852CN:User@JAMH-I7Send Stream Count 1CN:User@JAMH-I7ssrc: 3473334870Bytes rec 458249Bytes sent 104921Pkts recd 4610Pkts sent 4553 12:40:52 12:40:52
videochannels:1
org.jitsi.videobridge.VideoChannel Endpoint: 24b26b0aa Id:97ced0637812c9ff cb-id:24b26b0 sources localinitial=753397753 remote=4019089026 and =4019089026CN:User@JAMH-I7Send Stream Count 0Bytes rec 10280Bytes sent 160Pkts recd 202Pkts sent 10 12:40:52 12:40:52

There are far fewer packets being recieved on the video channel when you would ahve though there would eb a lot more data.

Clearly the bridge thinks the video channel is muted coming in. Hence it is not surprising it is not sending much out and chrome thinks it is muted (because it is).

Can anyone please give me a hint where to look as to the test of muting of a channel in?

On 26/01/2017 21:43, Boris Grozev wrote:

On 26/01/2017 14:11, John Hemming wrote:

Further on this I have discovered that the mediastreamtrack is only
muted after it is attached to a video element (Which can be a constraint
problem). Looking at the stream itself it appears that a small number
of packets of data (about 24 I think) are streamed to the client before
it stops (probably because the client has not responded asking for more,
but I don't know that much about the control channel).

You may be running into the following: In order to work around a bug in Chrome, when the connection is initially established, jitsi-videobridge will send a certain amount of "black" video frames to the receiver. If the sender sends no video, these will be the only packets the receiver gets, and since they just encode a completely black image, it will freeze in black. See the LipSyncHack class in the bridge.

Regards,
Boris

_______________________________________________
dev mailing list
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


#7

I have looked at a low level at what might be filtering out the packets. It looks like quite a few packets are being filtered out (quite large ones which may mean they are video) as the packetfilter being used is either StunDatagramPacketFilter or DtlsDatagramFilter. I wonder if really the filter being used should be RctpDemuxPacketFilter

The relevant method is acceptBySocketsOrThis(DatagramPacket p)

Question 1.

Am I potentially barking up the right tree?

Question 2.

How can I check what lists of potential multiplexed filters there are. The JSON returns rctp-mux for the channel bundle so that should be OK.

···

On 31/01/2017 12:43, John Hemming wrote:

I have written something to look at the mediastream stats for the live rtpchannels. It confirms what I thought:

org.jitsi.videobridge.AudioChannel Endpoint: 24b26b0aa Id:1fd3478442b438fa cb-id:24b26b0 sources localinitial=3473334870 remote=3018863852 and =3018863852CN:User@JAMH-I7Send Stream Count 1CN:User@JAMH-I7ssrc: 3473334870Bytes rec 458249Bytes sent 104921Pkts recd 4610Pkts sent 4553 12:40:52 12:40:52
videochannels:1
org.jitsi.videobridge.VideoChannel Endpoint: 24b26b0aa Id:97ced0637812c9ff cb-id:24b26b0 sources localinitial=753397753 remote=4019089026 and =4019089026CN:User@JAMH-I7Send Stream Count 0Bytes rec 10280Bytes sent 160Pkts recd 202Pkts sent 10 12:40:52 12:40:52

There are far fewer packets being recieved on the video channel when you would ahve though there would eb a lot more data.

Clearly the bridge thinks the video channel is muted coming in. Hence it is not surprising it is not sending much out and chrome thinks it is muted (because it is).

Can anyone please give me a hint where to look as to the test of muting of a channel in?

On 26/01/2017 21:43, Boris Grozev wrote:

On 26/01/2017 14:11, John Hemming wrote:

Further on this I have discovered that the mediastreamtrack is only
muted after it is attached to a video element (Which can be a constraint
problem). Looking at the stream itself it appears that a small number
of packets of data (about 24 I think) are streamed to the client before
it stops (probably because the client has not responded asking for more,
but I don't know that much about the control channel).

You may be running into the following: In order to work around a bug in Chrome, when the connection is initially established, jitsi-videobridge will send a certain amount of "black" video frames to the receiver. If the sender sends no video, these will be the only packets the receiver gets, and since they just encode a completely black image, it will freeze in black. See the LipSyncHack class in the bridge.

Regards,
Boris

_______________________________________________
dev mailing list
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


#8

I have found what is causing my problem. The bridge filters out Rtp packets in the multiplexing sockets where the payload number is different to one given to the bridge. Chrome is using 111 and I have only asked the bridge to handle 100 and 127 (following the example in the videobridge REST API - how to do it page). I have changed my status page to give details of what the filters are looking for:

MultiplexedDatagramSocket 0 -1 /2001:0:5ef5:79fb:206e:cba:ae6b:cdbe RtpChannelDatagramFilter bound open AudioChannel 111: RTP
MultiplexedDatagramSocket 0 -1 /2001:0:5ef5:79fb:206e:cba:ae6b:cdbe RtpChannelDatagramFilter bound open AudioChannel 111: RTCP
MultiplexedDatagramSocket 0 -1 /2001:0:5ef5:79fb:206e:cba:ae6b:cdbe RtpChannelDatagramFilter bound open VideoChannel 127:100: RTP
MultiplexedDatagramSocket 0 -1 /2001:0:5ef5:79fb:206e:cba:ae6b:cdbe RtpChannelDatagramFilter bound open VideoChannel 127:100: RTCP
MultiplexedDatagramSocket 0 -1 /2001:0:5ef5:79fb:206e:cba:ae6b:cdbe DTLSDatagramFilter bound open

Obviously I have two solutions:

a) To give more details to the bridge

b) To use the local description to tell chrome only to use 100 or 127.

That, however, explains why the RTCP was getting through, but not the RTP.

I have tried a) and now I get a rather laggy video element displaying what I think I am sending to the bridge. That, obviously, is much better than just getting nothing and I am now in a different place on this. It is also clear from Sawbuck that I am sending two video streams to the bridge and getting two back although I am actually only handling one properly. I also get some sounds that I think are from the change of speaker being recognised (even though it is not actually happening).

I will upload my status class and the version of HandlerImpl that enables it to run. I would make the point that my status class is a bit of a bodge in that it requires making visible all sorts of things in other classes that should not be visible. It does, however, give a good indication of what is actually going on. It also requires the stastics to be enabled.

I can see that one operational problem with the bridge is that when it does not work it is not that easy to find out why.

···

On 31/01/2017 17:53, John Hemming wrote:

I have looked at a low level at what might be filtering out the packets. It looks like quite a few packets are being filtered out (quite large ones which may mean they are video) as the packetfilter being used is either StunDatagramPacketFilter or DtlsDatagramFilter. I wonder if really the filter being used should be RctpDemuxPacketFilter

The relevant method is acceptBySocketsOrThis(DatagramPacket p)

Question 1.

Am I potentially barking up the right tree?

Question 2.

How can I check what lists of potential multiplexed filters there are. The JSON returns rctp-mux for the channel bundle so that should be OK.

On 31/01/2017 12:43, John Hemming wrote:

I have written something to look at the mediastream stats for the live rtpchannels. It confirms what I thought:

org.jitsi.videobridge.AudioChannel Endpoint: 24b26b0aa Id:1fd3478442b438fa cb-id:24b26b0 sources localinitial=3473334870 remote=3018863852 and =3018863852CN:User@JAMH-I7Send Stream Count 1CN:User@JAMH-I7ssrc: 3473334870Bytes rec 458249Bytes sent 104921Pkts recd 4610Pkts sent 4553 12:40:52 12:40:52
videochannels:1
org.jitsi.videobridge.VideoChannel Endpoint: 24b26b0aa Id:97ced0637812c9ff cb-id:24b26b0 sources localinitial=753397753 remote=4019089026 and =4019089026CN:User@JAMH-I7Send Stream Count 0Bytes rec 10280Bytes sent 160Pkts recd 202Pkts sent 10 12:40:52 12:40:52

There are far fewer packets being recieved on the video channel when you would ahve though there would eb a lot more data.

Clearly the bridge thinks the video channel is muted coming in. Hence it is not surprising it is not sending much out and chrome thinks it is muted (because it is).

Can anyone please give me a hint where to look as to the test of muting of a channel in?

On 26/01/2017 21:43, Boris Grozev wrote:

On 26/01/2017 14:11, John Hemming wrote:

Further on this I have discovered that the mediastreamtrack is only
muted after it is attached to a video element (Which can be a constraint
problem). Looking at the stream itself it appears that a small number
of packets of data (about 24 I think) are streamed to the client before
it stops (probably because the client has not responded asking for more,
but I don't know that much about the control channel).

You may be running into the following: In order to work around a bug in Chrome, when the connection is initially established, jitsi-videobridge will send a certain amount of "black" video frames to the receiver. If the sender sends no video, these will be the only packets the receiver gets, and since they just encode a completely black image, it will freeze in black. See the LipSyncHack class in the bridge.

Regards,
Boris

_______________________________________________
dev mailing list
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


#9

Error in the linked email.

Chrome is using 116 for video. 111 for Audio is OK because that is what I told the bridge.

···

On 01/02/2017 10:13, John Hemming wrote:

I have found what is causing my problem. The bridge filters out Rtp packets in the multiplexing sockets where the payload number is different to one given to the bridge. Chrome is using 111 and I have only asked the bridge to handle 100 and 127 (following the example in the videobridge REST API - how to do it page). I have changed my status page to give details of what the filters are looking for:

MultiplexedDatagramSocket 0 -1 /2001:0:5ef5:79fb:206e:cba:ae6b:cdbe RtpChannelDatagramFilter bound open AudioChannel 111: RTP
MultiplexedDatagramSocket 0 -1 /2001:0:5ef5:79fb:206e:cba:ae6b:cdbe RtpChannelDatagramFilter bound open AudioChannel 111: RTCP
MultiplexedDatagramSocket 0 -1 /2001:0:5ef5:79fb:206e:cba:ae6b:cdbe RtpChannelDatagramFilter bound open VideoChannel 127:100: RTP
MultiplexedDatagramSocket 0 -1 /2001:0:5ef5:79fb:206e:cba:ae6b:cdbe RtpChannelDatagramFilter bound open VideoChannel 127:100: RTCP
MultiplexedDatagramSocket 0 -1 /2001:0:5ef5:79fb:206e:cba:ae6b:cdbe DTLSDatagramFilter bound open

Obviously I have two solutions:

a) To give more details to the bridge

b) To use the local description to tell chrome only to use 100 or 127.

That, however, explains why the RTCP was getting through, but not the RTP.

I have tried a) and now I get a rather laggy video element displaying what I think I am sending to the bridge. That, obviously, is much better than just getting nothing and I am now in a different place on this. It is also clear from Sawbuck that I am sending two video streams to the bridge and getting two back although I am actually only handling one properly. I also get some sounds that I think are from the change of speaker being recognised (even though it is not actually happening).

I will upload my status class and the version of HandlerImpl that enables it to run. I would make the point that my status class is a bit of a bodge in that it requires making visible all sorts of things in other classes that should not be visible. It does, however, give a good indication of what is actually going on. It also requires the stastics to be enabled.

I can see that one operational problem with the bridge is that when it does not work it is not that easy to find out why.

On 31/01/2017 17:53, John Hemming wrote:

I have looked at a low level at what might be filtering out the packets. It looks like quite a few packets are being filtered out (quite large ones which may mean they are video) as the packetfilter being used is either StunDatagramPacketFilter or DtlsDatagramFilter. I wonder if really the filter being used should be RctpDemuxPacketFilter

The relevant method is acceptBySocketsOrThis(DatagramPacket p)

Question 1.

Am I potentially barking up the right tree?

Question 2.

How can I check what lists of potential multiplexed filters there are. The JSON returns rctp-mux for the channel bundle so that should be OK.

On 31/01/2017 12:43, John Hemming wrote:

I have written something to look at the mediastream stats for the live rtpchannels. It confirms what I thought:

org.jitsi.videobridge.AudioChannel Endpoint: 24b26b0aa Id:1fd3478442b438fa cb-id:24b26b0 sources localinitial=3473334870 remote=3018863852 and =3018863852CN:User@JAMH-I7Send Stream Count 1CN:User@JAMH-I7ssrc: 3473334870Bytes rec 458249Bytes sent 104921Pkts recd 4610Pkts sent 4553 12:40:52 12:40:52
videochannels:1
org.jitsi.videobridge.VideoChannel Endpoint: 24b26b0aa Id:97ced0637812c9ff cb-id:24b26b0 sources localinitial=753397753 remote=4019089026 and =4019089026CN:User@JAMH-I7Send Stream Count 0Bytes rec 10280Bytes sent 160Pkts recd 202Pkts sent 10 12:40:52 12:40:52

There are far fewer packets being recieved on the video channel when you would ahve though there would eb a lot more data.

Clearly the bridge thinks the video channel is muted coming in. Hence it is not surprising it is not sending much out and chrome thinks it is muted (because it is).

Can anyone please give me a hint where to look as to the test of muting of a channel in?

On 26/01/2017 21:43, Boris Grozev wrote:

On 26/01/2017 14:11, John Hemming wrote:

Further on this I have discovered that the mediastreamtrack is only
muted after it is attached to a video element (Which can be a constraint
problem). Looking at the stream itself it appears that a small number
of packets of data (about 24 I think) are streamed to the client before
it stops (probably because the client has not responded asking for more,
but I don't know that much about the control channel).

You may be running into the following: In order to work around a bug in Chrome, when the connection is initially established, jitsi-videobridge will send a certain amount of "black" video frames to the receiver. If the sender sends no video, these will be the only packets the receiver gets, and since they just encode a completely black image, it will freeze in black. See the LipSyncHack class in the bridge.

Regards,
Boris

_______________________________________________
dev mailing list
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

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