<p>Benjamin Keith Ford <strong>posted comments</strong> on this change.</p><p><a href="https://gerrit.asterisk.org/9224">View Change</a></p><p>Patch set 2:</p><p style="white-space: pre-wrap; word-wrap: break-word;">Open to suggestions on all of these, wanted to discuss here in case anyone felt strongly one way or another.</p><p>(3 comments)</p><ul style="list-style: none; padding-left: 20px;"><li><p><a href="https://gerrit.asterisk.org/#/c/9224/2/res/res_rtp_asterisk.c">File res/res_rtp_asterisk.c:</a></p><ul style="list-style: none; padding-left: 20px;"><li><p style="margin-bottom: 4px;"><a href="https://gerrit.asterisk.org/#/c/9224/2/res/res_rtp_asterisk.c@6749">Patch Set #2, Line 6749:</a> <code style="font-family:monospace,monospace">                               /* Define our starting point, or recover from a large gap of lost packets */</code></p><p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;">If that happened for the large gap case is it possible that there would be </blockquote></p><p style="white-space: pre-wrap; word-wrap: break-word;">My idea to work around this is to pull everything from the buffer, queue it like we would if we had hit the buffer max, and then add the frame we received to the end and pick up from there. That way, if it was a cycle, we get those frames we had stored and it should be like a seamless transition, and if it was a gap, it will play the catch up game and then resume video in the present state.</p></li><li><p style="margin-bottom: 4px;"><a href="https://gerrit.asterisk.org/#/c/9224/2/res/res_rtp_asterisk.c@6777">Patch Set #2, Line 6777:</a> <code style="font-family:monospace,monospace">                                    ast_data_buffer_put(rtp->recv_buffer, seqno, f);</code></p><p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;">What happens if we can't dupe the frame here? Will things pile up until we </blockquote></p><p style="white-space: pre-wrap; word-wrap: break-word;">For this one I have a couple different ideas. The first idea is queuing a &ast_null_frame (if that can be inserted into the list). The second idea is doing similar to what I proposed for the above case, going through buffer and queuing frames, then adding this frame in the appropriate spot, but using rtp->f to retain the data rather than duping it, since we will be using it now rather than later. Personally I like the second idea more, since the first could maybe result in many null frames being passed through rather than video, and I think we would all rather have video than a null frame.</p></li><li><p style="margin-bottom: 4px;"><a href="https://gerrit.asterisk.org/#/c/9224/2/res/res_rtp_asterisk.c@6785">Patch Set #2, Line 6785:</a> <code style="font-family:monospace,monospace">                                               /* We don't want missing sequence number duplicates */</code></p><p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;">Can you extend the comment to explain the scenario where this would happen?</blockquote></p><p style="white-space: pre-wrap; word-wrap: break-word;">I've got a decent little scenario I added to this comment that should better explain how this could happen, dealing with very, very out of order packets :)</p></li></ul></li></ul><p>To view, visit <a href="https://gerrit.asterisk.org/9224">change 9224</a>. To unsubscribe, visit <a href="https://gerrit.asterisk.org/settings">settings</a>.</p><div itemscope itemtype="http://schema.org/EmailMessage"><div itemscope itemprop="action" itemtype="http://schema.org/ViewAction"><link itemprop="url" href="https://gerrit.asterisk.org/9224"/><meta itemprop="name" content="View Change"/></div></div>

<div style="display:none"> Gerrit-Project: asterisk </div>
<div style="display:none"> Gerrit-Branch: 15 </div>
<div style="display:none"> Gerrit-MessageType: comment </div>
<div style="display:none"> Gerrit-Change-Id: Idab644b08a1593659c92cda64132ccc203fe991d </div>
<div style="display:none"> Gerrit-Change-Number: 9224 </div>
<div style="display:none"> Gerrit-PatchSet: 2 </div>
<div style="display:none"> Gerrit-Owner: Benjamin Keith Ford <bford@digium.com> </div>
<div style="display:none"> Gerrit-Reviewer: Benjamin Keith Ford <bford@digium.com> </div>
<div style="display:none"> Gerrit-Reviewer: Jenkins2 </div>
<div style="display:none"> Gerrit-Reviewer: Joshua Colp <jcolp@digium.com> </div>
<div style="display:none"> Gerrit-Reviewer: Sean Bright <sean.bright@gmail.com> </div>
<div style="display:none"> Gerrit-Comment-Date: Thu, 21 Jun 2018 19:57:26 +0000 </div>
<div style="display:none"> Gerrit-HasComments: Yes </div>