[Live-devel] High bit-rate (CBR) 4K streaming over a wireless link ...

[Shyam Kaundinya]

Oops! Typo here…

#2 should read …
Do I need to also modify the

increaseSendBufferTo

and
      sysctl net.core.wmem_max = the_maximum_buffer_size_that_you_need
as well to match the receivebuffer ?


From: Shyam Kaundinya <shyam.kaundinya at digitalforcetech.com>
Date: Tuesday, August 28, 2018 at 8:07 AM
To: "live-devel at lists.live555.com" <live-devel at lists.live555.com>
Subject: High bit-rate (CBR) 4K streaming over a wireless link ...

Hi

My product involves streaming high bit rate (>15M) 4K video over a high-bit rate wireless link. I use LIVE555 proxy server on both sides. Based on reviewing the forum articles, I have made the following changes, to accommodate the high bit rate and an unreliable link.


  1.  I replaced all occurances of

       increaseReceiveBufferTo
and
      sysctl net.core.rmem_max = the_maximum_buffer_size_that_you_need
with a large size value.

Re: the_maximum_buffer_size_that_you_need
What’s a good value to use here for 4K CBR at high-bit rate (>15M) ? 4K max uncompressed size is = 4096*2160*3=26,542,080. That seems somewhat excessive. I am not sure if using any other value would just be totally arbitrary. Is there a guaranteed minimum compression that a H.265 encoder can guarantee irrespective of what the scene is ? If so, I can arrive at my buffer size based on that information.


  1.  Do I need to also modify the

increaseSendBufferTo

and
      sysctl net.core.rmem_max = the_maximum_buffer_size_that_you_need
as well to match the receivebuffer ?


  1.  At times I see significant latency on the Rx side. But when I disconnect and reconnect the client, it seems to go away. If I leave it running, the virtual memory used by live keeps on increasing steadily and then live crashes and exits. Any thoughts on what could cause this behavior ?

Regards
Shyam

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20180828/9955f0bd/attachment-0001.html>