At least on Windows (and possibly on Linux), FD_SET must be called
always before calling select() or else it won't work and on Linux
the struct timeval values are changed to relect the amount of time
spent waiting on the file descriptors.
Using kvzRTP is far from easy on Windows so something must be done
about it at some point. Maybe QtCreator's/Visual Studio's deploy
tools could be used to help the installation procedure
Notify hooks are similar to receive hooks where kvzRTP calls the application
with some data.
Notification can be about, for example, that the timer for a frame
expired and it was dropped and the application should prepare for
possible consequences (f.ex. a gray screen)
There's a race condition between creating a stream (starting the
frame receiver) and installing a receive hook. Previously the recv_hook_
pointer contained garbage which caused problems especially on Windows.
There is a possibility that the dispatcher thread is started before
its state is initialized which causes it to appear as inactive when
it tries to enter the send loop and actually exists early.
This is a clear design flaw in the runner class but for the time
being this disgusting fix will have to suffice.
The code did not wait for dispatcher to actually stop but just issued
a termination and proceeded to release all memory which sometimes
caused use-after-free memory issues
34ms is too strict a deadline for some use cases. By increasing the
default frame delay to 100ms does not hurt the cases where the frames
are anyway received within 34 milliseconds but it also allows users
to stream at high resolutions/low QP values without recompling the library.
Making this adjustment dynamic based on timestamps of the packets is
a planned future task but this shall act as a bandaid until then.
RTP format was not set using the set_payload() function which
caused the clock rate to be 0. This in turn caused packets to appear
as duplicate or late by even minutes.
MinGW seems to employ some very aggressive optimizations that
sometimes create invalid packets because both Start and End
flags are set simultaneously.
This fixes the problem where an intra frame seems to be dropped
every now and then. Nothing was actually dropped but kvzRTP
received an invalid packet and thus discarded the whole frame
To be honest, I have no idea why this worked but it did anyway.
Let user create as many sessions as wanted with the same IP.
kvzRTP really does not care how many sessions with the same IP is
going on so forcing only one session per IP made no sense.
Now, however, the burden of releasing the session object is on the
caller when the application exits.
If the receiver is not listening to the port we're sending packets to,
we receive an ICMP Port Unreachable message to our socket which causes
recvfrom() to fail when it's called the next time. By ignoring these
messages we can continue the session
Aaro Altonen
Aaro Altonen
Joni Räsänen