GNOME Bugzilla – Bug 793765
rtpopuspay doesn't support clock-rate=16000
Last modified: 2018-02-26 09:20:30 UTC
Created attachment 368837 [details] [review] Patch RFC7587 says that the clock-rate for Opus payload is 48000. However... I need to transport Opus in a wire protocol which has timestamps at 16kHz. Making this work with FarStream is *much* saner if I just pretend to be RTP and use fsrtpconference. That means FarStream will then do the jitterbuffer and Opus encoding for me; all of which I have to reimplement if I attempt to use fsrawconference instead. Not to mention the fact that Pidgin 2.12.0 *crashes* when I attempt to use fsrawconference. With an RTP clock-rate of 16000 I can just transpose the RTP timestamps into my own wire protocol and everything works nicely. With 48000 I can *receive* OK because I just multiply the value in the wire protocol by three to create the RTP header, but the opposite direction is more problematic because I'd need to divide by three and somehow keep track of what the high bits should contain, when the RTP@48000 timestamp value wraps, but my wire@16000 shouldn't. So, please could we allow rtpopuspay/rtpopusdepay to support clock-rate=16000?
Opus is always 48000, libopus resamples.
I'm not quite sure why that is relevant to the clock-rate of the 'timestamp' field in the RTP packets. The wire protocol I'm working with needs a timestamp field, equivalent to the timestamp in RTP packets, which works at a frequency of 16000HZ. With the patch above, I can simply convert the RTP into my own wire protocol and the timestamps can be copied between the two as-is. Without the patch, I end up having to regenerate timestamps somehow for the outbound traffic. (In fact what I have right now is my *own* subclass of rtpbasepay, because that way I can deal with bug 793763 too, *and* interoperate with FarStream 0.2.7 by only having a single encoding-name instead of a list. But I'd *like* to get everything working without such hacks, of course.)
The Opus RTP RFC only supports 48000, so diverging from that would IMHO be problematic. This is similar to basically all video codecs only supporting 90000.
Fair enough, I'll stick with shipping my own rtpXXXpay implementation which is a cut-and-paste of rtpopuspay, with the clock-rate and number of channels hard-coded. As noted in comment #2 I get to kill three birds with one stone that way anyway. Thanks.