Subsequently a good test could be increase buffer_size like suggested, and if it is still not perfect as he observed then increase _max Reflecting back on it we don't need to play with wmem values, it just happens the project that put me onto this does read and write streams. This may have unintended consequences for server ram usage as each connection will default to the larger size. Using _default I believe bypasses the buffer_size option by telling the OS to default to this larger size buffer. Note size wise VLC and LIVE555 are both defaulting buffer size to 2000000. But they reference _max as an OS level limitation that will prevent the buffer size from working when you do increase it. It may well be a combination of both values that fixes it, VLC and LIVE555 talk about buffer size.
Could that be the root of the I don't pretend to fully understand it, but here is my current theory.
Would you mind explaining the difference between your solution (increasing the kernel's UDP buffer) and the option mentioned by (to set the ffmpeg "buffer_size" parameter)?Īlso, any idea why the kernel's UDP buffer makes a difference? Shouldn't the kernel be delivering the UDP datagrams to ffmpeg, and leaving the responsibility to ffmpeg to wait until it has received an entire video frame before rendering it on screen? I would appreciate it if you could share your understanding of the issue, and whether or not a fix is possible (or if the fix is to just increase the OS buffer as you've done).Īlso, do you have any guidelines for setting an appropriate buffer size, based on the bit rate, resolution, and frame rate of the video?Įdit: From this page, it seems like the "buffer_size" parameter is supported for udp:// URLs, but not for rtsp://.
0 kommentar(er)
