GStreamer JPEG 2000 Workflows

[Aaron Boxer]

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.

You mentioned that j2k file size is larger than jpeg encoded file size. One
of the features of JPEG 2000
is that you have complete control over the file size /  bit rate, through
rate control, and also that
for the same bit rate, JPEG 2000 decompressed image quality is superior to
JPEG decompressed image quality.
This is because of the J2K sub band decomposition, vs JPEG 8x8 block
decomposition.

It is certainly possible to reduce the size of compressed images. I guess
we simply do not have
a gstreamer property to set the bit rate. This is easily fixed.

As for the speed in general of OpenJPEG, I am working on a faster codec.
It is possible to significantly speed things up using multi-core, SIMD, and
even GPU acceleration.

Cheers,
Aaron






On Sun, Jun 26, 2016 at 4:10 AM, Mailing List SVR <lists at svrinformatica.it>
wrote:

> Hi Aaron,
>
> first of all thanks for your efforts,
>
> I'm not a J2K user, I evaluated this codec some years ago but was not
> suitable for my needs,
>
> in my use case I get video from network cameras and I can save or restream
> using the same codec or a different codec (for example jpeg2000). My input
> is never encoded as jpeg2000 (some cameras support jpeg2000 but they
> support h264 too)
>
> The main reason to transcode is to reduce bandwidth and/or change the
> original stream (add a text overlay, rotate the images ecc..)
>
> major problem with jpeg2000 is that encoding/decoding seems terribly slow
> and encoder does not save bandwidth.
>
> Please take a look at the following pipelines
>
> gstreamer compiled against openjpeg 1.5.2
>
> gst-launch-1.0 videotestsrc num-buffers=100 ! openjpegenc ! fakesink
> silent=false sync=false
> Impostazione della pipeline a PAUSED ...
> La pipeline è in PREROLLING ...
> La pipeline è in PREROLLED ...
> Impostazione della pipeline a PLAYING ...
> New clock: GstSystemClock
> Ottenuto EOS dall'elemento «pipeline0».
> *Execution ended after 0:00:08.701328003*
> Impostazione della pipeline a PAUSED ...
> Impostazione della pipeline a READY ...
> Impostazione della pipeline a NULL ...
> Esecuzione di free sulla pipeline...
>
> gstreamer compiled against openjpeg 2.1
>
>  gst-launch-1.0 videotestsrc num-buffers=100 ! openjpegenc ! fakesink
> silent=false sync=false
> Setting pipeline to PAUSED ...
> Pipeline is PREROLLING ...
> Pipeline is PREROLLED ...
> Setting pipeline to PLAYING ...
> New clock: GstSystemClock
> Got EOS from element "pipeline0".
> *Execution ended after 0:00:26.328685923*
> Setting pipeline to PAUSED ...
> Setting pipeline to READY ...
> Setting pipeline to NULL ...
> Freeing pipeline ...
>
> Now the same pipeline with other encoders:
>
> gst-launch-1.0 videotestsrc num-buffers=100 ! vp8enc ! fakesink
> silent=false sync=false
> Setting pipeline to PAUSED ...
> Pipeline is PREROLLING ...
> Redistribute latency...
> Pipeline is PREROLLED ...
> Setting pipeline to PLAYING ...
> New clock: GstSystemClock
> Got EOS from element "pipeline0".
> *Execution ended after 0:00:01.459543338*
> Setting pipeline to PAUSED ...
> Setting pipeline to READY ...
> Setting pipeline to NULL ...
> Freeing pipeline ...
>
> gst-launch-1.0 videotestsrc num-buffers=100 ! jpegenc ! fakesink
> silent=false sync=false
> Setting pipeline to PAUSED ...
> Pipeline is PREROLLING ...
> Pipeline is PREROLLED ...
> Setting pipeline to PLAYING ...
> New clock: GstSystemClock
> Got EOS from element "pipeline0".
> *Execution ended after 0:00:00.052316056*
> Setting pipeline to PAUSED ...
> Setting pipeline to READY ...
> Setting pipeline to NULL ...
> Freeing pipeline ...
>
> I don't know if the problem is inside openjpeg or in gstreamer integration
> however this codec is actually too slow for my use case, decoder seems slow
> too and produced files have a bigger size than for example the ones
> obtained with jpegenc,
>
> is there some "magic" property to set to improve performance?
>
> thanks
> Nicola
>
> P.S. if you try avenc_jpeg2000 you'll get better performance so maybe the
> problem is in openjpeg
>
>
> Il 25/06/2016 17:22, Aaron Boxer ha scritto:
>
> Dear GStreamers,
>
> I've spent the last month or so trying to improve J2K support inside
> GStreamer ( with a lot of help from the GStreamer gurus :) )
>
> I am very curious about how people are using GStreamer to stream J2K
> content.
> Are there many people streaming J2K over RTP ?  Are people transcoding J2K
> assets
> to other formats such as H.264 or HEVC ?  How much interest is there in
> supporting
> J2K over MPEG TS  ? What about motion J2K ?
>
> Any feedback on what people are doing, and what they would like to see,
> would be most welcome.
>
> Thanks!
> Aaron
>
>
> _______________________________________________
> gstreamer-devel mailing listgstreamer-devel at lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160626/b81a98b1/attachment.html>