| Age | Commit message (Collapse) | Author |
|---|
|
Not going on master since this is all kind of complicated, but it's useful
to have around as a stress test
|
|
This fixes the funky colours :-)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Signal handling now uses an inproc transport to send a message to the main
thread instead of acting on SIGINT and other termination signals and using
a global variable to signal alarm expiration (yuck).
This also changes the main/receiver thread architecture which now uses
zmq_poll() and gives us the additional advantage of being able to poll for
GUI events regularly. This solves the problem of the receive mode UI freezing
when the sender has gone away.
|
|
This is to demonstrate how SIGINT, etc. can be handled properly even if the
application thread is blocked on zmq_recv().
|
|
Doesn't work quite as well as I would like it to, but until 0MQ has queue
limits implemented it's useful if you want to test a large video stream on
e.g. 802.11g wifi.
Also added proper option handling using getopt().
|
|
|
|
Raw video streams require large amounts of bandwidth. For example a
640x480 RGB24 stream at 15 frames per second will consume around 100 Mbps.
This code adds a bandwidth and fps display in the window title on the
receiving side so that you can see the bandwidth requirements for the
stream being sent.
|
|
|
|
An inproc:// endpoint must exist before we can connect to it. This change
removes the silly sleep(1) hack to wait for the sender thread to come online
and instead does the zmq_bind() in the main thread and the zmq_connect() in the
sender thread.
|
|
|
|
|
|
|
