[Bug 793765] New: rtpopuspay doesn't support clock-rate=16000

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=793765

            Bug ID: 793765
           Summary: rtpopuspay doesn't support clock-rate=16000
    Classification: Platform
           Product: GStreamer
           Version: 1.x
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: dwmw2 at infradead.org
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 368837
  --> https://bugzilla.gnome.org/attachment.cgi?id=368837&action=edit
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 at 48000 timestamp value wraps, but my wire at 16000 shouldn't.

So, please could we allow rtpopuspay/rtpopusdepay to support clock-rate=16000?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.