GStreamer JPEG 2000 Workflows

Aaron Boxer boxerab at gmail.com
Mon Jun 27 12:56:56 UTC 2016


On Mon, Jun 27, 2016 at 3:43 AM, Sebastian Dröge <sebastian at centricular.com>
wrote:

> On So, 2016-06-26 at 09:46 -0400, Aaron Boxer wrote:
> > Ni Nicola,
> >
> > Thanks for running these experiments - I didn't know about the timing
> feature in gstreamer.
> > It is interesting that openjpeg 2.1 is about 3 times slower than
> openjpeg 1.5. Since the core
> > encoding is not that different between the versions, the only
> explanation I can think of
> > is that the test source is monochrome, and openjpeg 2.1 encoder is
> treating it as RGB or YUV.
> > I will definitely take a look.
>
> OpenJPEG 2.1 has a different API that is less efficient to use for
> GStreamer. More copying is going on, but I can't remember details.
>
> IIRC I told you about that a few weeks ago on this list already :)
>

Yes, I remember you did mention it. Both versions of openjpeg use 32 bit
fixed point calculations, so the uncompressed
data is always copied into a second buffer (unsigned 32 bit int) before
compression.  2.0 introduced a streaming API
so that the entire uncompressed image did not have to be stored in memory.
So, there may be a little more copying
with streaming, but it should add a negligible amount of time to
compression.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160627/ec6e8d59/attachment-0001.html>


More information about the gstreamer-devel mailing list