Updated UltraGrids video pipeline to use threading in two key areas

[aw-sohonet]

• Sending packets
  • This causes the sending of packets using the RTP stack to be threaded amongst all available CPU threads.
  • This was implemented because sending uncompressed / lossless frames at 24 FPS was often taking longer to send the frame than than the duration of the frame. As the frames are collected in the same thread that they are sent in, this can cause a slowing in the collection of frames. Currently this option is forced. Future work will make this optional.
  • A huge increase in performance has been measured, such that lossless / uncompressed frames are able to be processed quickly enough on consumer hardware (that has enough thread capability).
  • A parameter has been introduced to control the amount of avaialble threads to be used for encoding ("encode-thread-count").
• Receiving packets
  • Due to the nature of the way packets are received in UltraGrid there has been two threading implementations placed into the decode pipeline.
  • The first of which is that decoding the packets into the initial package is now run in a thread independently of the build-up of packets. This helps avoid queues in the kernel for incoming UDP packets.
  • The second of which is a series of threads that are used to decrypt the contents of the packets and place them into the frame. These threads do not lock when writing into the frame (as each packet should represent an independent region of the memory).
  • A parameter has been introduced to control the amount of available thread to be used for decoding and decrypting packets ("decode-thread-count").

Some fixes for the Reed Solomon implementation for audio have also been introduced (mostly focused on a memory leak that existed in the implementation). A fix has also been implemented to remove the packet shaping from the audio FEC RTP send function that was causing a crash.