The payload format must be known when creating the Connection object
because Connection owns the frame queue and frame queue needs the format
in order to allocate correct media-specific headers for transactions
This is a generic way of sending multiple packets with one system call.
It takes a pointer to vecio_buf (mmsghdr on Linux, TRANSMIT_PACKETS_ELEMENT
on Windows) and vecio_buf length and calls either sendmmsg(2) or TransmitPackets()
The API didn't change much, if user wishes to use HEVC slices
(and thus preserve the state between push_frame() calls), he must
call the push_frame() with RTP_SLICE and RTP_MORE flags, like this:
push_frame(conn, data, 123, RTP_SLICE | RTP_MORE);
push_frame(conn, data, 456, RTP_SLICE | RTP_MORE);
push_frame(conn, data, 789, RTP_SLICE | RTP_MORE);
push_frame(conn, data, 100, RTP_SLICE);
RTP_MORE preserves the state between push_frame() calls and when the
last slice is given to kvzRTP, the RTP_MORE flags must be removed.
This flushes the frame queue and deinitializes it.
Some of the more complex relocations still don't work, invalid and
duplicate packets wreck havoc and frame reallocation is missing but
it's already able to receiver stream with very large packets gracefully.
Separate them to different files and make it configurable which to use.
By default the normal receiver is used and if use gives __RTP_USE_OPTIMISTIC_RECEIVER__
then the optimistic receiver is started.
Small frames work, larger frames are sometimes dropped. This is supposed
to reduce the amount of copying but the performance will degrade as
network load increases
Probation zone lives below the actual payload and can be used as a
temporary storage for fragments that cannot be relocated.
It's part of the larger memory block so the fragments that are copied
to probation zone are spatially very close to their actual place in
the array making relocation faster
More flag made it possible to give more data to the frame queue
(and thus return from __push_hevc_frame()).
This is not actually possible because the fragment headers are stored
on the stack. That is why postponing the frame queue flush is not a good idea.
Make it mandatory to specify the payload when creating reader/writer.
Reader needs to type anyway because it must start the correct frame
receiver. For writer it's not absolutely necessary but this makes
the API cleaner
Examples are now in two categories:
- Simple examples that demonstrate the core concepts
- Full examples that show how the library can be used from
application's perspective
Simple example also contains two subfoldres: rtp and rtcp:
- rtp holds code snippets that show the RTP interface
- rtcp contains all snippets that have something to do with RTCP
Because the order of creation matters when initializing RTP connection,
RTCP was not initialized when create_rtcp() was called. Creating the
object when it's needed fixes the issue
Aaro Altonen