Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Play media and AMR(WB) codec

Open
  • Is something wrong?
#1,841 4 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
15/100
Issue type
Bug
Clarity
Needs clarification
Activity status
Stale
Domain
audio-video-rtc

Research direction

The payload gives only a playback log, so start by locating the playback encoder creation in the AMR transcoding path — the lines naming libopencore_amrnb, "Creating SSRC transcoder from PCM-S16LE/8000/1 to AMR/8000/1" and "Created media playback context" come from there — and check how the mode-set is turned into an initial rate. Then compare with the normal call path, where incoming CMR from the peer is honoured, to see where playback skips that handling. Done means the RTP dump's FT bits change after A sends CMR, but a maintainer should confirm the intended design first.

Written by the indexing model from the issue text.

Description

bug
rtpengine version the issue has been seen with

12.4.1.7+0~mr12.4.1.7

Used distribution and its version

AlmaLinux 8.10

Linux kernel version used

4.18.0-553.5.1

CPU architecture issue was seen on (see uname -m)

x86_64

Expected behaviour you didn't see

We have a call between A and B with media passing through rtpengine (12.4.7.1) and with the same codec on both sides "AMR/8000/mode-set=0,2,4,7; mode-change-period=2; mode-change-neighbor=1; max-red=0".
Then during the call we need to block media toward B and play some media wav file to A.
In the log I see following after play media command:

[core] Output codec for media playback is AMR/8000
[codec] Creating SSRC transcoder from PCM-S16LE/8000/1 to AMR/8000/1
[internals] supported sample format for output codec libopencore_amrnb: s16
[internals] using output sample format s16 for codec libopencore_amrnb
[core] Using 5900 as initial AMR bitrate based on mode-set
[core] Initialized encoder with frame size 160 samples
[internals] supported sample format for input codec pcm_s16le: s16
[codec] Encoder created with clockrate 8000, 1 channels, using sample format 1 (ptime 20 for 160 samples per frame and 160 samples (40 bytes) per packet, bitrate 6700)
[codec] Created media playback context for PCM-S16LE/8000/ -> AMR/8000/mode-set=0,2,4,7; mode-change-period=2; mode-change-neighbor=1; max-red=0

After that A hears that playing media ok but in RTP dump I see that rtpengine keeps enconding rate constant during the whole playing (FT bits: AMR 5,90 kbit/s (2)) despite the fact that the peer CMR from A allows encoder to switch to a higher speed rate.
Please advice if it's possible for encoder to follow the CMR from the peer during play media.
It looks that the behaviour is the same with AMR-WB codec and it does not depend on rtpengine version, we tested also with 11.2.1.5.
Is there additional data I need to provide?

Unexpected behaviour you saw

No response

Steps to reproduce the problem

No response

Additional program output to the terminal or logs illustrating the issue

No response

Anything else?

No response

Dominant language
Perl
Stars
992
Forks
459
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from sipwise/rtpengine

All issues in sipwise/rtpengine

Similar issues

More Perl issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.