<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 18, 2018 at 4:57 PM, Mathieu Duponchelle <span dir="ltr"><<a href="mailto:mathieu@centricular.com" target="_blank">mathieu@centricular.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"><span class="gmail-"><br></span>
That's interesting, for context I was the one that upstreamed the
ulpfec elements,<br>
but I didn't do the implementation, how can the fec decoder
determine that?</div></blockquote><div><br></div><div>I hope I am not mistaken since it's now only 2nd time I look at rfc5109:</div><div><pre class="gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0);font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial"><span class="gmail-h3" style="line-height:0pt;display:inline;white-space:pre;font-family:monospace;font-size:1em;font-weight:bold"><h3 style="line-height:0pt;display:inline;white-space:pre;font-family:monospace;font-size:1em;font-weight:bold"><a class="gmail-selflink" name="section-8.1" href="https://tools.ietf.org/html/rfc5109#section-8.1" style="color:black;text-decoration:none">8.1</a>. Generation of the FEC Header</h3></span></pre>...</div><pre class="gmail-newpage" style="font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0);font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial"> o Unsigned network-ordered 16-bit representation of the media
packet length in bytes minus 12 (for the fixed RTP header),
i.e., the sum of the lengths of all the following if present:
the CSRC list, extension header, RTP payload, and RTP padding
(16 bits)</pre><div><br class="gmail-Apple-interchange-newline">So the length of original RTP packet is actually encoded into FEC packet header. Now when we run recovery on </div><div>all the available FEC levels and the resulting packet has same length as stated in FEC header, we know the full packet got recovered. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">
I assume that this concern only exists when using
faststart-min-packets, correct?</div></blockquote><div> </div><div>My concern is following: I want to decode all frames as soon as possible since every millisecond of latency counts. Jitter doesn't </div><div>matter to me. I set jitterbuffer latency parameter to fairly large value since in bad network case I don't want jitterbuffer to time </div><div>out easily when waiting for missing packet (and I also have RTX). Now if the FEC recovery is only done after jitterbuffer times out then </div><div>I get the whole jitterbuffer latency worth of additional delay added in cases where I actually had all the needed data available </div><div>inside FEC packet. However if I run FEC and recover packet before jitterbuffer then jitterbuffer will not delay the frame at all.</div><div><br></div><div>--</div><div>LauriE</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><span class="gmail-">
<br>
<div class="gmail-m_5117099983665834701moz-signature">-- <br>
Mathieu Duponchelle · <a href="https://www.centricular.com" target="_blank">https://www.centricular.com</a></div>
</span><blockquote type="cite"><span class="gmail-">
<div dir="ltr">
<div><br>
</div>
<div>--</div>
<div>LauriE</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, May 16, 2018 at 3:43 PM,
Mathieu Duponchelle <span dir="ltr"><<a href="mailto:mathieu@centricular.com" target="_blank">mathieu@centricular.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Lauri,<br>
<span><br>
<br>
<br>
On 05/14/2018 02:53 PM, Lauri Ehrenpreis wrote:<br>
> Hi!<br>
><br>
> I tried to set up a pipeline which does both
retransmissions and FEC for video. My hope was that first
pipeline will try to recover packet with FEC and if that
fails it will request retransmission. As there was no
working example for such setup I
used gst-plugins-good/tests/ex<wbr>amples/rtp/client-rtpaux.c
and gst-plugins-good/tests/exa<wbr>mples/rtp/server-rtpaux.c
as basis and added request-fec-decoder
& request-fec-encoder signal handlers there. <br>
><br>
> After adding FEC handlers gstrtpbin came up with
following pipeline on client side (attached image). So
retransmission component is before jitterbuffer and FEC is
after. Do I understand correctly the pipeline will first
try to request retransmission if packet is lost and only
after the retransmission did not deliver the packet in
time for jitterbuffer, it will try use FEC to recover
packet? Why it is done this way - wouldn't it be better to
try FEC first?<br>
<br>
</span>Yes, you are correct, FEC recovery will only be
attempted once a packet is actually<br>
considered lost.<br>
<br>
While we could indeed reconstruct packets as soon as they
are late, there is no<br>
guarantee that the reconstructed packet would be "complete",
at least with ULPFEC.<br>
<br>
As you might already know, ULP stands for "uneven level
protection", and works based<br>
on the assumption that with most video codecs / payloaders,
the most important part<br>
of a packet is at the start, which means that a percentage
of protection can be applied<br>
at the packet level by only protecting the initial portion,
possibly making exceptions<br>
for keyframe packets for example, which could be fully
protected.<br>
<br>
This means that while we could reconstruct a packet, if
retransmission has been<br>
enabled it makes sense to ask for that packet to be
retransmitted anyway.<br>
<br>
I hope that made sense :)<br>
<span class="gmail-m_5117099983665834701HOEnZb"><font color="#888888"><br>
-- <br>
Mathieu Duponchelle · <a href="https://www.centricular.com" rel="noreferrer" target="_blank">https://www.centricular.com</a><br>
</font></span></blockquote>
</div>
<br>
</div>
<br>
<fieldset class="gmail-m_5117099983665834701mimeAttachmentHeader"></fieldset>
<br>
</span><pre>______________________________<wbr>_________________
gstreamer-devel mailing list
<a class="gmail-m_5117099983665834701moz-txt-link-abbreviated" href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.<wbr>freedesktop.org</a>
<a class="gmail-m_5117099983665834701moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/gstreamer-<wbr>devel</a>
</pre>
</blockquote>
</div>
</blockquote></div><br></div></div>