Possible bug in rtpjpegpay and/or rtpjpegdepay.

[Nicolas Dufresne]

Le jeudi 13 juillet 2017 à 16:04 -0400, Stirling Westrup a écrit :
> 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?

rtpjpegpay/depay are not implicated in this issue. Setting the buffer-
size for your use case on udpsrc/sink is something we normally do for
high rate streaming. The kernel default (4K) is pretty small. For the
kernel side, it's unclear to me why it is so small, I would need to
research a bit more the subject.

I know that in high throughput servers, it pretty common to tweak the
linux kernel. Those settings are usually placed in /etc/sysctl.d/. As
these are split files, you can ship a config as part of your
application (dropbox does that to increase the number of FD you can
watch with inotify).

Nicolas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20170713/a67c963d/attachment.sig>