GStreamer arch and latency

[Aaron Boxer]

On Sun, May 15, 2016 at 2:04 AM, Sebastian Dröge <sebastian at centricular.com>
wrote:

> On Sa, 2016-05-14 at 12:28 -0400, Aaron Boxer wrote:
> > I don't really understand the underlying design, but I have a question
> about latency:
> >
> > I notice that the rtp payloader assumes that a complete video frame is
> available before
> > it starts payloading. Would it not give better perf and lower latency if
> the payloader
> > could begin processing as the MTUs come in over the wire?
>
> The payloader is (usually) processing data that does not come over the
> wire, and in many cases it also needs to be able to look at the
> complete frame first before actually doing something.
>
> For the depayloader, e.g. rtph264depay should (or could) output
> individual NALs instead of complete AUs but as our decoder also work on
> frame-units this wouldn't help much. It would however be beneficial to
> change that in some situations, it just has to be done.
>


Thanks. Since J2K supports tiling, tiles could be processed (encoded,
decoded, etc)
before the entire frame is present.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160515/403e59ef/attachment.html>