<div dir="ltr"><div dir="ltr">On Wed, Mar 13, 2019 at 10:15 AM Dan Cropp <<a href="mailto:dan@amtelco.com">dan@amtelco.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-US">
<div class="gmail-m_-6622646276158505346WordSection1">
<p class="MsoNormal">Using asterisk 16.1.1.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I’m setting up a test using the cmp2k (Cyber Mega Phone 2K Ultimate Dynamic Edition).<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I have noticed Chrome 72 had some issues with video streams. I just upgraded to Chrome 73 and see they still have some issues. If I have 2 calls in a confbridge with video set to none. I then set the video source to a Chrome browser
and the Remote Video shown to both calls from Firefox and Chrome do not update. However, if I set the video source to the Firefox browser, my Remote Video is accurate in both Firefox and Chrome.<u></u><u></u></p>
<p class="MsoNormal">I confirmed that asterisk is indicating the video source changed by looking at the AMI BridgeVideoSourceUpdate event.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">When I use the Firefox (65.0.2) browser I can set either call to be the video source and the Remote Video updates accordingly.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Is this caused by Chrome’s video sent to asterisk being some format which asterisk can’t use in the confbridge? </p></div></div></blockquote><div><br></div><div>The way I understand it is that video stream has changed, so the browser needs some way to know that. Otherwise the decoder thinks it's invalid data and drops it. In these cases either Asterisk needs to issue a renegotiation (currently not supported), or the codec needs to contain video stream information in their payload. I spoke with Joshua Colp about this some as he's had some dealings with this and he had the following to say:</div><div><br></div><div>"Some codecs (such as VP8/V9) embed information about the video stream within their payload. Asterisk does not currently rewrite this information, so when a stream change occurs in Asterisk using the selective source functionality this can cause the receiving side (the browser) to drop the payload as it sees it as not being part of the existing stream. Different browsers can behave differently, such as resetting the video decoder to<span style="font-weight:bold;color:rgb(204,0,0)"> </span>handle the new stream. Rewriting this information in the video payload is not currently supported."<br></div><div><br></div><div>So you are probably seeing it work or not in Chrome vs Firefox due to browser, and codec support of such occurrences.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> .... <snip config> ....</blockquote></div><br clear="all"><div>-- <br></div><div dir="ltr" class="gmail_signature"><div dir="ltr">Kevin Harwell<div>Digium - A Sangoma Company | Senior Software Developer<div>445 Jan Davis Drive NW - Huntsville, AL 35806 - US</div><div>Check us out at: <a href="https://digium.com" target="_blank">https://digium.com</a> & <a href="https://asterisk.org" target="_blank">https://asterisk.org</a></div></div></div></div></div>