Possible bug in rtpjpegpay and/or rtpjpegdepay.

[Stirling Westrup]

Thanks for the workaround. We've tested it and it works in our environment,
but it leaves us wondering at its necessity. Will we have to do this in
production, or is there some other fix that could be applied to
jpegpay/depay?


On Thu, Jul 13, 2017 at 3:35 PM, Nicolas Dufresne <nicolas at ndufresne.ca>
wrote:

> Hello,
>
> Le jeudi 13 juillet 2017 à 13:25 -0400, Stirling Westrup a écrit :
> > It seems that one or the other of the two elements has trouble
> > correctly dealing with fragmented jpeg images. As the size of the
> > images increase, one starts getting lots and lots of warnings and
> > dropped frames from rtpjepgdepay:
> >
> > 0:00:14.129355327 19338      0x1b11370 WARN            rtpjpegdepay
> > gstrtpjpegdepay.c:760:gst_rtp_jpeg_depay_process:<rtpjpegdepay0>
> > discarding data packets received when we have no header
>
> I was testing your scripts, and notice that packets are dropped by the
> receiving socket. I could workaround the issue locally.
>
> 1. By increasing kernel UDP memory: sysctl -w net.core.rmem_max=26214400
> 2. Increase client socket buffer size in client: buffer-size=$((512*1024))
>
> Note that it works with smaller rmem_max value. It also seems to work
> with receiver buffer-size of 256 kb. I'm not sure how one calculate the
> requirement for these.
>
> regards,
> Nicolas
>
> >
> > Here are our test pipelines. Please let us know if this is an actual
> > bug, or if we are doing something wrong. We've found that with
> > MTU=1400 and QUAL=75, we start dropping long (multi-second) sequences
> > of frames. If we set MTU to 64000, we have almost no dropped frames,
> > and if we set QUAL=5 we have no trouble with dropped frames (although
> > the image is terrible).
> >
> > SERVER:
> > #!/bin/bash
> >
> > PATH="/home/sti/Videos/BBB"
> > FILE="bbb_sunflower_1080p_30fps_normal.mp4"
> > MTU=1400
> > QUAL=75
> > PATHNAME="$PATH/$FILE"
> >
> > /usr/bin/gst-launch-1.0                             \
> >   rtpbin ntp-time-source=1 ntp-sync=true buffer-mode=synced
> > name=sendbin \
> >   filesrc location="$PATHNAME" ! qtdemux ! h264parse ! avdec_h264
> >  \
> >     ! videoconvert ! queue ! jpegenc quality=$QUAL ! rtpjpegpay
> > mtu=$MTU \
> >     ! sendbin.send_rtp_sink_0                         \
> >   sendbin.send_rtp_src_0                         \
> >     ! udpsink port=25000 host="127.0.0.1"                 \
> >   sendbin.send_rtcp_src_0                         \
> >     ! udpsink port=25001 host="127.0.0.1" sync=false async=false
> >  \
> >   udpsrc port=25005 ! sendbin.recv_rtcp_sink_0
> >
> > --8<---CUT HERE--->8--
> > CLIENT:
> >
> > #!/bin/bash
> >
> > /usr/bin/gst-launch-1.0   \
> >   rtpbin name=rtpbin                            \
> >   udpsrc port=25000                             \
> >     ! application/x-rtp,media=video,payload=26,encoding-name=JPEG
> > \
> >     ,clock-rate=90000 ! rtpbin.recv_rtp_sink_0                \
> >   rtpbin. ! rtpjpegdepay ! queue ! jpegparse ! jpegdec ! videoconvert
> >     \
> >     ! ximagesink display=:0                        \
> >   udpsrc port=25001 ! rtpbin.recv_rtcp_sink_0                \
> >   rtpbin.send_rtcp_src_0                        \
> >     ! udpsink port=25005 host="127.0.0.1" sync=false async=false
> >
> >
> >
> > _______________________________________________
> > gstreamer-devel mailing list
> > gstreamer-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel




-- 
Stirling Westrup
Programmer, Entrepreneur.
https://www.linkedin.com/e/fpf/77228
http://www.linkedin.com/in/swestrup
http://technaut.livejournal.com
http://sourceforge.net/users/stirlingwestrup
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20170713/d559f1bd/attachment.html>