GStreamer JPEG 2000 Workflows
Locked
GStreamer JPEG 2000 Workflows
 
|
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 :) )_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: GStreamer JPEG 2000 Workflows
|
|
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:
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: GStreamer JPEG 2000 Workflows
|
|
Ni Nicola, Thanks for running these experiments - I didn't know about the timing feature in gstreamer.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 <[hidden email]> wrote:
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: GStreamer JPEG 2000 Workflows
|
|
In reply to this post by Mailing List SVR
Hi Nicola, I ran some tests using the latest master version of gstreamer and openjpeg.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. Cheers, Aaron On Sun, Jun 26, 2016 at 4:10 AM, Mailing List SVR <[hidden email]> wrote:
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: GStreamer JPEG 2000 Workflows
|
|
In reply to this post by boxerab@gmail.com
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 :) -- Sebastian Dröge, Centricular Ltd · http://www.centricular.com _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
signature.asc (968 bytes)
Re: GStreamer JPEG 2000 Workflows
|
|
In reply to this post by boxerab@gmail.com
Hi Aaron,
thanks for your answers and your efforts Il 26/06/2016 19:29, Aaron Boxer ha scritto:
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
this is good!
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
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: GStreamer JPEG 2000 Workflows
|
|
In reply to this post by Sebastian Dröge-3
Hi Aaron, thanks for your work on improve J2K support inside GStreamer. I like to see that Jpeg2000 become more and more popular. We use Gstreamer mainly for transcoding e.g H246 -> some J2K container like MPEG-TS or MXF and also for streaming MPEG-TS over RTP protocol There are some features we like to have in MPEG-TS like support for J2K(which I'm working on) or support for NULL packets in MPEG-TS which is good for constant bitrate when you are streaming ... On Mon, Jun 27, 2016 at 9:43 AM, Sebastian Dröge <[hidden email]> wrote: On So, 2016-06-26 at 09:46 -0400, Aaron Boxer wrote: Miloš Selečéni GPU Developer | Comprimato Systems s.r.o. _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: GStreamer JPEG 2000 Workflows
|
|
On Mon, Jun 27, 2016 at 5:22 AM, Miloš Selečéni <[hidden email]> wrote:
Thanks, interesting. Are you using RTP for MPEG-TS because the MPEG-TS muxer does not support J2K ?
Interesting. Perhaps we can combine our efforts on the MPEG-TS J2K support. Aaron
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: GStreamer JPEG 2000 Workflows
|
|
In reply to this post by Sebastian Dröge-3
On Mon, Jun 27, 2016 at 3:43 AM, Sebastian Dröge <[hidden email]> wrote: On So, 2016-06-26 at 09:46 -0400, Aaron Boxer wrote: 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. _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |