opusrtp: Implement DTX support

[phil-lavin]

Implemented DTX support into opusrtp
Also had to properly implement the --rate parameter as 48000 was hard coded in 2 places

[mark4o]

Opus streams are sample rate independent, and the audio bandwidth can change in the middle of the stream, so Opus in RTP normalizes all timestamps to 48000 Hz (https://tools.ietf.org/html/rfc7587#section-6.1). Therefore these changes are not correct. The only purpose of the opusrtp sample rate option is when writing an Ogg Opus output file, there is a field that can optionally record the original sample rate, and this option allows that field to be filled in.

[mark4o]

Ideally, timestamp gaps due to either DTX or packet loss would be handled according to https://tools.ietf.org/html/rfc7845#section-4.1 (it is the same basic idea as this but a little more sophisticated). The main reason that this is not implemented is because currently opusrtp does not handle out-of-order packets. Instead of a small glitch, this change would cause huge gaps to be inserted whenever packets are received out of order. In addition to handling out-of-order packets, there should be some kind of sanity checks to ensure that the data is reasonable before using it to generate a large number of packets, to protect against bad or malicious data. Also, it is possible that multiple streams were inadvertently captured, which would cause this change to produce an explosion of output with a huge number of packets written for each packet received, since each received packet would be on a different stream with a different time base. Before this is implemented there should be some checks to ensure that the data is from a single stream, to avoid this issue. Alternatively, different streams could be written to different files. A while back I did add checks for matching port number and RTP payload type, which catches some common reasons for mixed up streams, however that is not enough to ensure that all packets are from the same stream.

If you are interested in adding support for out-of-order packets, sanity checks, and same-stream checks then that would be terrific and this could be added as well, but I think it is important that those be added first, and at least the out-of-order packet support is probably much more work. Therefore I am leaving this pull request open for now.