MJPEG Pipeline Very Slow

[Dwight Kulkarni]

Hi Tim,

I rechecked the CPU and it turns out that if I run gst-launch-1.0  it is
only using 25% of the CPU, and it's actually faster than what I reported.
The latency is 1 second or so, and the fps is 2-3 fps. When I run it
through my application that includes g-streamer library it slows down a lot
more and has a 6 second delay and barely 1 fps, so that might indicate a
different problem in the application.

My question is that if gst-launch-1.0 is only using up 25% of the CPU but
it is not meeting my frame rate needs, is there a way to use more cores
from the gst-launch-1.0 command ?

On Wed, Aug 11, 2021 at 2:58 PM Dwight Kulkarni <dwight at realtime-7.com>
wrote:

> Hi Tim,
>
>
> *Can you quantify that? Is it delayed? Does it have a much lower framerate
> than expected? Both?*
>
> *>> There is a 6 second delay and the frame rate is around 1 fps. For
> testing, we have tried a VLC client rtsp network stream, and also used the
> following Gstreamer command:*
>
> *src: *
> gst-launch-1.0 v4l2src device=/dev/video1 ! video/x-raw, width=1920,
> height=1080, framerate=15/1 ! jpegenc ! rtpjpegpay name=pay0 pt=96 !
> udpsink host=192.168.1.50 port=5000
>
>
> *client:*
> gst-launch-1.0 udpsrc port=5000 ! application/x-rtp, encoding-name=JPEG,
> payload=96 ! rtpjpegdepay ! jpegparse ! jpegdec ! autovideosink
>
>
>
>
> *What kind of camera is the v4l2 device here? Many USB cameras and webcams
> will be able to output JPEG directly, in which case you could save the jpeg
> encoding step.*
>
> *>>Camera sensor is OV5640 by OmniVision over MIPI   *
> *>>Regarding JPEG output, our current camera is by default giving out RAW
> BAYER output. We are looking into if it is possible to have the sensor
> output JPEG, when I tried your pipeline with current settings, it gave an
> error as shown below.*
>
>
>
> gst-launch-1.0 v4l2src device=/dev/video1 ! image/jpeg, width=1920,
> height=1080, framerate=15/1 ! queue  max-size-bytes=50000000
> max-size-time=500000000 max-size-buffers=10  ! jpegparse ! identity
> sync=true ! queue max-size-bytes=50000000 max-size-time=500000000
> max-size-buffers=10  ! rtpjpegpay name=pay0 pt=96 ! udpsink
> host=192.168.1.50 port=5000
>
> Setting pipeline to PAUSED ...
> Pipeline is live and does not need PREROLL ...
> Setting pipeline to PLAYING ...
> New clock: GstSystemClock
> ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Internal
> data stream error.
> Additional debug info:
> ../../../../git/libs/gst/base/gstbasesrc.c(3072): gst_base_src_loop ():
> /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
> streaming stopped, reason not-negotiated (-4)
> Execution ended after 0:00:00.000647375
> Setting pipeline to PAUSED ...
> Setting pipeline to READY ...
> Setting pipeline to NULL ...
> Freeing pipeline ...
>
> On Wed, Aug 11, 2021 at 2:04 PM Tim Müller <tim at centricular.com> wrote:
>
>> Hi Dwight,
>>
>> > I am trying to stream MJPEG on my IMX8MPLUS. I am using the following
>> > pipeline, was wondering if you can comment on if there is a way to
>> > make this faster, I have tried two permutations with the queue and
>> > without.
>> >
>> > The resulting stream is extremely laggy.
>>
>> Can you quantify that? Is it delayed? Does it have a much lower
>> framerate than expected? Both?
>>
>> What's the receiving application / pipeline you're checking with?
>>
>>
>>
>> > 2)
>> > gst-launch-1.0 v4l2src device=/dev/video1 ! video/x-raw, width=1920,
>> > height=1080, framerate=15/1 ! queue ! jpegenc ! queue ! rtpjpegpay
>> > name=pay0 pt=96 ! udpsink host=192.168.1.50 port=5000
>> >
>>
>> queues are good here.
>>
>> What kind of camera is the v4l2 device here? Many USB cameras and
>> webcams will be able to output JPEG directly, in which case you could
>> save the jpeg encoding step.
>>
>> Try
>>
>> gst-launch-1.0 v4l2src device=/dev/video1 !
>> image/jpeg,width=1920,height=1080,... ! queue ! rtpjpegpay ! ..
>>
>> Might also be worth checking if the JPEG encoding maxes out any of your
>> cores to see if that might be limiting throughput.
>>
>> Cheers
>>  Tim
>>
>>
>>
>
> --
> Sincerely,
>
> Dwight Kulkarni
>
>

-- 
Sincerely,

Dwight Kulkarni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20210812/667712cb/attachment.htm>