G.729B decoder not available.

[sameerthapaevontech]

Summary of the bug:
G.729A/B codec decoder not available. ffmpeg is not able to convert file with audio data encoded as G.729B to wav or mp3
How to reproduce:

% ffmpeg -f g729 -i audio.g729 -acodec pcm_s16le -ar 8000 output.wav

ffmpeg version 2.8.15
built with gcc 4.8.5 (GCC) 20150623 (Red Hat 4.8.5-28) on CentOS Linux release 7.5.1804 (Core)

[sameerthapaevontech]

audio data encoded by G.729 B codec

[Carl Eugen Hoyos]

Please test current FFmpeg git head before reporting issues here.

[sameerthapaevontech]

Now I compiled ffmpeg source code from github.

ffmpeg version N-92671-g0e8eb07 Copyright (c) 2000-2018 the FFmpeg developers
built with gcc 4.8.5 (GCC) 20150623 (Red Hat 4.8.5-28)
on CentOS Linux release 7.5.1804 (Core)

command:
ffmpeg -i audio.g729 -acodec pcm_s16le -ar 8000 output.wav

output:
ffmpeg version N-92671-g0e8eb07 Copyright (c) 2000-2018 the FFmpeg developers

built with gcc 4.8.5 (GCC) 20150623 (Red Hat 4.8.5-28)
configuration:
libavutil 56. 24.101 / 56. 24.101
libavcodec 58. 42.100 / 58. 42.100
libavformat 58. 24.100 / 58. 24.100
libavdevice 58. 6.101 / 58. 6.101
libavfilter 7. 46.101 / 7. 46.101
libswscale 5. 4.100 / 5. 4.100
libswresample 3. 4.100 / 3. 4.100

[g729 @ 0x2c234c0] Estimating duration from bitrate, this may be inaccurate
Guessed Channel Layout for Input Stream #0.0 : mono
Input #0, g729, from '7a6e3680-bed16aaa-1a1-1603a8c0.g729':

Duration: 00:00:19.31, start: 0.000000, bitrate: 8 kb/s

Stream #0:0: Audio: g729, 8000 Hz, mono, s16

Stream mapping:

Stream #0:0 -> #0:0 (g729 (native) -> pcm_s16le (native))

Press [q] to stop, ? for help
Output #0, wav, to 'audio.wav':

Metadata:

ISFT : Lavf58.24.100
Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 8000 Hz, mono, s16, 128 kb/s
Metadata:

encoder : Lavc58.42.100 pcm_s16le

7a6e3680-bed16aaa-1a1-1603a8c0.g729: corrupt input packet in stream 0
[g729 @ 0x2c25100] Packet size 4 is unknown.
Error while decoding stream #0:0: Invalid data found when processing input
size= 302kB time=00:00:00.25 bitrate=9840.0kbits/s speed=2.16x
video:0kB audio:302kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.025246%

[Carl Eugen Hoyos]

Which software decodes the provided file differently? How was the file created?

[sameerthapaevontech]

I am developing an application that listens for RTP data using GStreamer and converts the received raw data packets using FFMPEG. It works well for codes: PCMA, PCMU, G722 and G729 and converts the received audio files into wav and mp3. But the conversion fails when G729b stream is received. FFMPEG has support for G729 but nothing is mentioned about G729a/b. I didn't find any other library/software that can decode G729b to wav or mp3.

Cisco call manager (CUCM) sends voip call data to recording server. Our app is on the recording server where gstreamer stores the rtp data. For g729 the gstreamer pipeline is: udpsrc port=5008 caps="application/x-rtp,channels=(int)1,media=(string)audio,payload=(int)18,clock-rate=(int)8000,encoding-name=(string)G729" ! rtpg729depay ! filesink.
Call is made through cisco IP phones and softphones, which means they can decode and play the codec.

[Carl Eugen Hoyos]

Did you explain how you created the file you attached?

I don't know how the 2-byte Silence Insertion Descriptor is supposed to be detected, the following command lines allow to guess that the file likely contains SID's:

$ ffplay -skip_initial_bytes 0 audio.g729
$ ffplay -skip_initial_bytes 2 audio.g729
$ ffplay -skip_initial_bytes 4 audio.g729
$ ffplay -skip_initial_bytes 6 audio.g729
$ ffplay -skip_initial_bytes 8 audio.g729

I wonder if only the rtp level can detect the SID, and it may therefore be impossible to decode the provided file.

Not necessarily related: Why are you not using FFmpeg's rtp stack?

[Carl Eugen Hoyos]

Replying to sameerthapaevontech:

I am developing an application that listens for RTP data using GStreamer and converts the received raw data packets using FFMPEG. It works well for codes: PCMA, PCMU, G722 and G729 and converts the received audio files into wav and mp3.

But the conversion fails when G729b stream is received.

Do you agree that the conversion does not fail but that you do not like 80% of the output?

[sameerthapaevontech]

Replying to cehoyos:

Did you explain how you created the file you attached?

File is created by gstreamer that uses "rtpg729depay" depayloader to extract g729 audio data from rtp.

I don't know how the 2-byte Silence Insertion Descriptor is supposed to be detected, the following command lines allow to guess that the file likely contains SID's:

$ ffplay -skip_initial_bytes 0 audio.g729
$ ffplay -skip_initial_bytes 2 audio.g729
$ ffplay -skip_initial_bytes 4 audio.g729
$ ffplay -skip_initial_bytes 6 audio.g729
$ ffplay -skip_initial_bytes 8 audio.g729

I wonder if only the rtp level can detect the SID, and it may therefore be impossible to decode the provided file.

Agreed. This might be possible that extraction from rtp is not correct.

Not necessarily related: Why are you not using FFmpeg's rtp stack?

Will try this.
Thank you!!!

[sameerthapaevontech]

Replying to cehoyos:

Replying to sameerthapaevontech:

I am developing an application that listens for RTP data using GStreamer and converts the received raw data packets using FFMPEG. It works well for codes: PCMA, PCMU, G722 and G729 and converts the received audio files into wav and mp3.

But the conversion fails when G729b stream is received.

Do you agree that the conversion does not fail but that you do not like 80% of the output?

Yes I do. By fail I mean output is not properly audible.

[Carl Eugen Hoyos]

See ​https://tools.ietf.org/html/rfc3551#section-4.5.6
The rtp layer has to detect the SDI frame (Annex B comfort noise frame) because of its size, I don't think this is possible with the file you provided.
I do not immediately see that FFmpeg's rtp layer signals that it does not support G.729B, this appears to be a bug in FFmpeg, apart from the missing feature of supporting comfort noise.