qiurui
/
uvgrtp-base
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Update README

This commit is contained in:
Aaro Altonen 2019-10-10 07:54:35 +03:00
parent d1a6d18adf
commit e6adf2ad21
1 changed files with 12 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
README.md
View File

@ -38,7 +38,8 @@ For kvzRTP we've used 3 methods to improve the send throughput:
* System call dispatching
* To improve the responsiveness of the library, application code only needs to call `push_frame()` which does the packetization and pushes the packets to a writer-specific frame queue. The actual sending is done by a separate thread called system call dispatcher (SCD). Its sole purpose is to take the packets from the frame queue and send them. This minimizes the delay experienced by the calling application and makes sending faster
System call batching and dispatching are very tightly-knit combination. Frame queue is internally implemented as a ring buffer of smaller buffers (or rather, slots for pointers to buffers). This ring buffer is filled by the caller using `enqueue_message()` and when `flush_queue()` is called, it will internally call `trigger_send()` in SCD's context. SCD locks the range given by `trigger_send()` and performs a batched system call. During that time, if more frames are given to kvzRTP, they're flexibly written to the ring buffer. If application pushes more data to kvzRTP than SCD can push out (the ring buffer is full), the `enqueue_message()` will wait on a mutex. The size of the ring buffer is configurable by `__RTP_FQUEUE_RING_BUFFER_SIZE__` and `__RTP_FQUEUE_RING_BUFFER_BUFFS_PER_PACKET__`
System call batching and dispatching are a very tightly-knit combination. Frame queue is implemented as a vector of media transactions. For every `push_frame()`, a new transaction entry is created. Transaction entries contain pointers to media frame, RTP headers and the outgoing address.
This model makes the sending very clean because for every input there's one discrete output record which can be processed immediately or given to SCD. It is, however, not mandatory to enable SCD if frame queue want to be used. SCD brings benefits (smaller delay experienced by the application, better throughput) but the downside is that there's yet another thread running in the background. The goal is the dedicate one physical core for SCDs to minimize cache thrashing.
Because of these optimizations, we're the [fastest at sending HEVC](https://google.com) (and AVC [not tested]). Basically we're fast at sending any media stream with frame sizes big and small that require packetization to MTU-sized chunks.
@ -133,7 +134,7 @@ NOTE 1: If you wish to use OFR, you need to supply the maximum payload size used
`__RTP_N_PACKETS_PER_SYSCALL__`
* How many packets should the OFR read per system call
* This is a double-edged sword because on the other you can reduce the overhead caused by system calls but it will in turn increase the amount of processing done by system call and may cause more complex relocations
* Setting this to 1, you can get rid of shifting completely
* Setting this to 1, you can get rid of shifting completely
`__RTP_MAX_PAYLOAD__`
* This defines the maximum payload used by sender (so only the actual HEVC data, all headers excluded).
@ -149,7 +150,6 @@ Use `__RTP_SILENT__` to disable all prints
Use `__RTP_USE_OPTIMISTIC_RECEIVER__` to enable the optimistic fragment receiver
* See src/formats/hevc.cc for more details
* NOTE: To use the receiver, you must be sure that no individual packet is larger than MTU (1500 bytes)
Use `__RTP_USE_PROBATION_ZONE__` to enable the probation zone allocation for RTP frames
* See src/frame.hh for more details
@ -166,12 +166,16 @@ Use `__RTP_MAX_PAYLOAD__` to determine the maximum UDP **payload** size
Use `__RTP_PROBATION_ZONE_SIZE__` to configure the probation zone is
* This should define the number of **packets** that fit into probation zone
`__RTP_FQUEUE_RING_BUFFER_SIZE__`
* How many UDP packets the ring buffer can hold (default is 1500)
Use `__RTP_MAX_QUEUED_MSGS__` to configure how many transaction entries the free queue can hold
* This can be rather low number for small amount of clients
* Default is 20
Use `__RTP_FQUEUE_RING_BUFFER_BUFFS_PER_PACKET__`
* How many buffers one UDP packet takes (default is 4 [RTP, NAL, FU and payload])
* NOTE: ring buffer default size is 4 * 1500 = 6000 elements
Use `__RTP_FQUEUE_MAX_SIZE__` to configure how many UDP packets one transaction entry holds
* Default is 500
Use `__RTP_FQUEUE_BUFFERS_PER_PACKET__`
* How many buffers does it take to construct one UDP packet
* Default is 4 (RTP, NAL, FU and payload)
Use `NDEBUG` to disable `LOG_DEBUG` which is the most verbose level of logging