<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, May 15, 2016 at 2:04 AM, Sebastian Dröge <span dir="ltr"><<a href="mailto:sebastian@centricular.com" target="_blank">sebastian@centricular.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sa, 2016-05-14 at 12:28 -0400, Aaron Boxer wrote:<br>
> I don't really understand the underlying design, but I have a question about latency:<br>
><br>
> I notice that the rtp payloader assumes that a complete video frame is available before<br>
> it starts payloading. Would it not give better perf and lower latency if the payloader<br>
> could begin processing as the MTUs come in over the wire?  <br>
<br>
</span>The payloader is (usually) processing data that does not come over the<br>
wire, and in many cases it also needs to be able to look at the<br>
complete frame first before actually doing something.<br>
<br>
For the depayloader, e.g. rtph264depay should (or could) output<br>
individual NALs instead of complete AUs but as our decoder also work on<br>
frame-units this wouldn't help much. It would however be beneficial to<br>
change that in some situations, it just has to be done.<br></blockquote><div><br><br></div><div>Thanks. Since J2K supports tiling, tiles could be processed (encoded, decoded, etc)<br></div><div>before the entire frame is present.<br></div><br></div><br></div></div>