Fwd: help : Regarding AMR-WB in gstreamer.

PIYUSH BADKUL piyushmact18 at gmail.com
Thu Aug 6 16:17:40 UTC 2020


Respected sir

I hope you are doing well and in good health'
I have two issues:

ISSUE1 -
I am using Kurento Media Server which in turn uses GStreamer.
 in our case of Transcoding from PCMA to AMR-WB, we hear the audio for a
starting time of 5 seconds, and then a total silence is observed.

I am getting a warning message in logs

0:00:27.154301569  4831 0x14d704002720 WARN         rtpsynchronizer
kmsrtpsynchronizer.c:561:kms_rtp_synchronizer_process_rtp_buffer_mapped:<
KmsRtpSynchronizer at 0x14d72c020d80> [Sorted mode] Fix PTS not increasing
monotonically, SSRC: 3037524492, seq: 526, rtp_ts: 127015436, ext_ts:
127015436, last: 0:00:13.743311941, current: 0:00:07.723311941, fixed = last
: 0:00:13.743311941
0:00:27.154397304  4831 0x14d704002720 WARN                kmsutils kmsutils
.c:1479:kms_utils_depayloader_adjust_pts_out:<rtppcmudepay0> Fix PTS
not strictly
increasing, last: 0:00:13.755311941, current: 0:00:13.743311941, fixed =
last + 1: 0:00:13.756311941
0:00:27.174221849  4831 0x14d704002720 LOG          rtpsynchronizer
kmsrtpsynchronizer.c:425:kms_rtp_synchronizer_process_rtp_buffer_mapped:<
KmsRtpSynchronizer at 0x14d72c020d80> RTP SSRC: 3037524492, Seq: 527
0:00:27.174277267  4831 0x14d704002720 WARN         rtpsynchronizer
kmsrtpsynchronizer.c:549:kms_rtp_synchronizer_process_rtp_buffer_mapped:<
KmsRtpSynchronizer at 0x14d72c020d80> Function Name
:kms_rtp_synchronizer_process_rtp_buffer_mapped
 File Name : /root/PIYUSH/kms-omni-build/kms-core/src/gst-plugins/commons/
kmsrtpsynchronizer.c  Line Number: 549
0:00:27.174299732  4831 0x14d704002720 WARN         rtpsynchronizer
kmsrtpsynchronizer.c:561:kms_rtp_synchronizer_process_rtp_buffer_mapped:<
KmsRtpSynchronizer at 0x14d72c020d80> [Sorted mode] Fix PTS not increasing
monotonically, SSRC: 3037524492, seq: 527, rtp_ts: 127015596, ext_ts:
127015596, last: 0:00:13.743311941, current: 0:00:07.743311941, fixed = last
: 0:00:13.743311941
0:00:27.174394041  4831 0x14d704002720 WARN                kmsutils kmsutils
.c:1479:kms_utils_depayloader_adjust_pts_out:<rtppcmudepay0> Fix PTS
not strictly
increasing, last: 0:00:13.756311941, current: 0:00:13.743311941, fixed =
last + 1: 0:00:13.757311941
0:00:27.174525946  4831 0x14d704002720 WARN           audioresample
gstaudioresample.c:1009:gst_audio_resample_check_discont:<audioresample1>
encountered
timestamp discontinuity of 304 samples = 0:00:00.038000000
0:00:27.194253540  4831 0x14d704002720 LOG          rtpsynchronizer
kmsrtpsynchronizer.c:425:kms_rtp_synchronizer_process_rtp_buffer_mapped:<
KmsRtpSynchronizer at 0x14d72c020d80> RTP SSRC: 3037524492, Seq: 528
0:00:27.194325675  4831 0x14d704002720 WARN         rtpsynchronizer
kmsrtpsynchronizer.c:549:kms_rtp_synchronizer_process_rtp_buffer_mapped:<
KmsRtpSynchronizer at 0x14d72c020d80> Function Name
:kms_rtp_synchronizer_process_rtp_buffer_mapped
 File Name : /root/PIYUSH/kms-omni-build/kms-core/src/gst-plugins/commons/
kmsrtpsynchronizer.c  Line Number: 549
0:00:27.194360607  4831 0x14d704002720 WARN         rtpsynchronizer
kmsrtpsynchronizer.c:561:kms_rtp_synchronizer_process_rtp_buffer_mapped:<
KmsRtpSynchronizer at 0x14d72c020d80> [Sorted mode] Fix PTS not increasing
monotonically, SSRC: 3037524492, seq: 528, rtp_ts: 127015756, ext_ts:
127015756, last: 0:00:13.743311941, current: 0:00:07.763311941, fixed = last
: 0:00:13.743311941


I am not getting any Error messages and just a print of timestamp
discontinuity in the interval of RTP packets
Something like this

mple0> encountered timestamp discontinuity of 960 samples =
0:00:00.060000000
0:00:26.934555639  4831 0x14d704002720 WARN           audioresample
gstaudioresample.c:1009:gst_audio_resample_check_discont:<audioresample1>
encountered timestamp discontinuity of 304 samples = 0:00:00.038000000
0:00:26.974570708  4831 0x14d704002720 WARN           audioresample
gstaudioresample.c:1009:gst_audio_resample_check_discont:<audioresample1>
encountered timestamp discontinuity of 304 samples = 0:00:00.038000000
0:00:27.014521594  4831 0x14d704002720 WARN           audioresample
gstaudioresample.c:1009:gst_audio_resample_check_discont:<audioresample1>
encountered timestamp discontinuity of 304 samples = 0:00:00.038000000
0:00:27.054561629  4831 0x14d704002720 WARN           audioresample
gstaudioresample.c:1009:gst_audio_resample_check_discont:<audioresample1>
encountered timestamp discontinuity of 304 samples = 0:00:00.038000000
0:00:27.094575209  4831 0x14d704002720 WARN           audioresample
gstaudioresample.c:1009:gst_audio_resample_check_discont:<audioresample1>
encountered timestamp discontinuity of 304 samples = 0:00:00.038000000
0:00:27.122462722  4831 0x14d7100018f0 WARN           audioresample
gstaudioresample.c:1009:gst_audio_resample_check_discont:<audioresample0>
encountered timestamp discontinuity of 640 samples = 0:00:00.040000000
0:00:27.134523890  4831 0x14d704002720 WARN           audioresample
gstaudioresample.c:1009:gst_audio_resample_check_discont:<audioresample1>
encountered timestamp discontinuity of 304 samples = 0:00:00.038000000
0:00:27.174525946  4831 0x14d704002720 WARN           audioresample
gstaudioresample.c:1009:gst_audio_resample_check_discont:<audioresample1>
encountered timestamp discontinuity of 304 samples = 0:00:00.038000000
0:00:27.214529149  4831 0x14d704002720 WARN           audioresample
gstaudioresample.c:1009:gst_audio_resample_check_discont:<audioresample1>
encountered timestamp discontinuity of 304 samples = 0:00:00.038000000
0:00:27.254541540  4831 0x14d704002720 WARN           audioresample
gstaudioresample.c:1009:gst_audio_resample_check_discont:<audioresample1>
encountered timestamp discontinuity of 304 samples = 0:00:00.038000000

I just want to ask whether is this a bug at GStreamer?

I have reason to believe so because the source(Telenet HardPhone) is
sending the correct packets as per RFC verified by me Twice.

I bug given below was for Opus, Maybe there is a chance that it can come
for AMR-WB. This issue is arising out of only one type of phone and for
rest other phones, the transcoding is working smoothly.

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

The above link talks about the same issue regarding the timestamp
discontinuity but in the case of Opus Codec. Can this be the same for
AMR-WB codec?
Just want your feedback.
This was completely random and difficult to produce at that time, maybe
that is the reason people have avoided it?


*I am happy to assist with any logs that you may require for the same.*


*ISSUE 2 - Does Gstreamer support AMR-WB Bandwidth Efficient. I am using
GStreamer-1.5.*

*when i did : *

* gst-inspect-1.5 rtpamrdepay*


Factory Details:
  Rank                     secondary (128)
  Long-name                RTP AMR depayloader
  Klass                    Codec/Depayloader/Network/RTP
  Description              Extracts AMR or AMR-WB audio from RTP packets
(RFC 3267)
  Author                   Wim Taymans <wim.taymans at gmail.com>

Plugin Details:
  Name                     rtp
  Description              Real-time protocol plugins
  Filename
/usr/lib/x86_64-linux-gnu/gstreamer-1.5/libgstrtp.so
  Version                  1.8.1.1
  License                  LGPL
  Source module            gst-plugins-good
  Source release date      2020-07-23 12:21 (UTC)
  Binary package           GStreamer Good Plugins (Ubuntu)
  Origin URL
https://launchpad.net/distros/ubuntu/+source/gst-plugins-good1.5

GObject
 +----GInitiallyUnowned
       +----GstObject
             +----GstElement
                   +----GstRTPBaseDepayload
                         +----GstRtpAMRDepay

Pad Templates:
  SRC template: 'src'
    Availability: Always
    Capabilities:
      audio/AMR
               channels: 1
                   rate: 8000
      audio/AMR-WB
               channels: 1
                   rate: 16000

  SINK template: 'sink'
    Availability: Always
    Capabilities:
      application/x-rtp
                  media: audio
             clock-rate: 8000
          encoding-name: AMR
            octet-align: 1
      application/x-rtp
                  media: audio
             clock-rate: 16000
          encoding-name: AMR-WB
           * octet-align: 1*


Element Flags:
  no flags set

Element Implementation:
  Has change_state() function: 0x148b1db19190

Element has no clocking capabilities.
Element has no URI handling capabilities.

Pads:
  SINK: 'sink'
    Pad Template: 'sink'
  SRC: 'src'
    Pad Template: 'src'

Element Properties:
  name                : The name of the object
                        flags: readable, writable
                        String. Default: "rtpamrdepay0"
  parent              : The parent of the object
                        flags: readable, writable
                        Object of type "GstObject"
  stats               : Various statistics
                        flags: readable
                        Boxed pointer of type "GstStructure"
                   clock_rate: 0
                                   npt-start: 0
                                    npt-stop: 18446744073709551615
                                  play-speed: 1
                                  play-scale: 1
                             running-time-dts: 18446744073709551615
                             running-time-pts: 18446744073709551615
                                      seqnum: 0
                                   timestamp: 0

*Also, in the documentation, there was no source of gstreamer supporting
AMR-WB Bandwidth Efficient (Octet-Align = 0). Please let me know whether it
is supported or not.*

*Please help us.*

Thanks

*Piyush Badkul* [Personal Website <http://opg7371.github.io/>]

*+91 8989412425  |* *+91 7987549194*

Designer | Developer (App Developer & Software Developer) | Blogger.

*Research Engineer at* *C-DOT <http://www.cdot.in/home.htm>* *| Co-Founder*
*(**YoCount*
<https://play.google.com/store/apps/details?id=org.shpstartup.android.yocount>
*)** |* *Curator (*CodesMyth <http://www.codesmyth.com/>*) *

Bachelor of Technology, Maulana Azad National Institute Of Technology,
Bhopal, India [An Institute of National Importance].

■ Android ■ Designer ■ Blogger ■ Developer

Note: This email and its attachments are confidential and are protected by
copyright. When addressed to our clients it is subject to our terms and
conditions of business. Unless specifically specified, the contents are for
information and discussion only
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20200806/be41465d/attachment-0001.htm>


More information about the gstreamer-devel mailing list