GStreamer JPEG 2000 Workflows
Mailing List SVR
lists at svrinformatica.it
Mon Jun 27 08:17:08 UTC 2016
Hi Aaron,
thanks for your answers and your efforts
Il 26/06/2016 19:29, Aaron Boxer ha scritto:
> Hi Nicola,
>
> I ran some tests using the latest master version of gstreamer and
> openjpeg.
>
> On my system (Ubuntu VM on i7 3770 host) , using the pipelines you
> suggested, I found the following
> timings:
>
> Openjpeg 2.1.X: 3.08 seconds
> VP8: 1.38 seconds
> JPEG: 0.054 seconds
I tested with git master too, I use gstreamer uninstalled with openjpeg
2.1 manually compiled and installed, on my system (arch linux on
i7-4700MQ real machine) openjpegenc performance are worse than yours,
probably I did something wrong
anyway even 3.08 seconds to encode 100 frames 352x288 is really too slow
(at least for my use case), vp8 is the slowest encoder, please compare
with openh264enc or x264enc (tune=zerolatency). With this numbers
openjpenenc is probably not able to do a real time encoding for
relatively low resolutions such as 640x480
>
> Also, my accelerated J2K codec took 1.04 seconds.
this is good!
>
> I didn't test 1.5, but there are so many bugs and security issues with
> 1.5 that I wouldn't recommend using it.
>
> So, the situation has improved with the latest versions.
>
> Also, I just noticed that openjpegenc uses the default encode
> parameters settings for OpenJPEG, and the default is *lossless*
> encoding. So, the compression ratio is never going to go much higher
> than 2:1. This will definitely affect file size.
for my use case if we can have a file size/time comparable with vp8/h264
encoder a similar time to encode is ok, but if file size is comparable
with jpeg encoder the encoding time should be comparable with jpegenc too,
regards,
Nicola
>
> Cheers,
> Aaron
>
>
>
> On Sun, Jun 26, 2016 at 4:10 AM, Mailing List SVR
> <lists at svrinformatica.it <mailto: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 list
>> gstreamer-devel at lists.freedesktop.org
>> <mailto:gstreamer-devel at lists.freedesktop.org>
>> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> <mailto: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/20160627/af42f41f/attachment-0001.html>
More information about the gstreamer-devel
mailing list