Opened 2 months ago

Last modified 2 months ago

#7604 reopened defect

G.729B decoder not available.

Reported by: sameerthapaevontech Owned by:
Priority: normal Component: undetermined
Version: git-master Keywords: rtp g729
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

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)

Attachments (1)

audio.g729 (18.9 KB) - added by sameerthapaevontech 2 months ago.
audio data encoded by G.729 B codec

Download all attachments as: .zip

Change History (10)

Changed 2 months ago by sameerthapaevontech

audio data encoded by G.729 B codec

comment:1 Changed 2 months ago by cehoyos

  • Keywords g729b removed
  • Priority changed from important to normal
  • Resolution set to invalid
  • Status changed from new to closed
  • Type changed from enhancement to defect
  • Version changed from 2.8.11 to unspecified

Please test current FFmpeg git head before reporting issues here.

comment:2 Changed 2 months ago by sameerthapaevontech

  • Resolution invalid deleted
  • Status changed from closed to reopened

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%

comment:3 Changed 2 months ago by cehoyos

  • Keywords g729 added
  • Summary changed from G.729A/B codec decoder not available. to G.729B decoder not available.
  • Version changed from unspecified to git-master

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

comment:4 follow-up: Changed 2 months ago by 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.

comment:5 follow-up: Changed 2 months ago by cehoyos

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?

comment:6 in reply to: ↑ 4 ; follow-up: Changed 2 months ago by 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?

comment:7 in reply to: ↑ 5 Changed 2 months ago by 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!!!

comment:8 in reply to: ↑ 6 Changed 2 months ago by 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.

comment:9 Changed 2 months ago by cehoyos

  • Component changed from avcodec to undetermined
  • Keywords rtp added

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.

Note: See TracTickets for help on using tickets.