<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 27, 2016 at 3:43 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 So, 2016-06-26 at 09:46 -0400, Aaron Boxer wrote:<br>
> Ni Nicola,<br>
><br>
> Thanks for running these experiments - I didn't know about the timing feature in gstreamer.<br>
> It is interesting that openjpeg 2.1 is about 3 times slower than openjpeg 1.5. Since the core <br>
> encoding is not that different between the versions, the only explanation I can think of<br>
> is that the test source is monochrome, and openjpeg 2.1 encoder is treating it as RGB or YUV.<br>
> I will definitely take a look.<br>
<br>
</span>OpenJPEG 2.1 has a different API that is less efficient to use for<br>
GStreamer. More copying is going on, but I can't remember details.<br>
<br>
IIRC I told you about that a few weeks ago on this list already :)<br></blockquote><div><br></div><div>Yes, I remember you did mention it. Both versions of openjpeg use 32 bit fixed point calculations, so the uncompressed<br></div><div>data is always copied into a second buffer (unsigned 32 bit int) before compression.  2.0 introduced a streaming API<br></div><div>so that the entire uncompressed image did not have to be stored in memory. So, there may be a little more copying<br></div><div>with streaming, but it should add a negligible amount of time to compression. <br><br></div><div>I think there was a regression in 2.0 that affected performance, and this seemingly has been fixed in the latest 2.1.1 release.<br></div></div><br></div></div>