Opened 22 hours ago

Closed 17 hours ago

#11364 closed defect (invalid)

µ-law: pcm_mulaw files incorrectly shown as "s16", actually 8 bit per sample

Reported by: Marcus Müller Owned by:
Priority: minor Component: ffprobe
Version: 6.1.1 Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Summary of the bug: ffprobe (6.1.2)/ffplay/ffmpeg incorrectly show

Stream #0:0: Audio: pcm_mulaw ([7][0][0][0] / 0x0007), 48000 Hz, 1 channels, s16, 384 kb/s

when inspecting a µ-law PCM file.

If you divide 384 kb/s / (48000 Hz), you get the actual (and correct for G.711 µ-law) 8 b per sample.

How to reproduce:

# get some example linear pcm
curl https://opus-codec.org/static/examples/samples/speech_orig.wav > orig.wav
ffmpeg -i orig.wav -c:a pcm_mulaw mulaw.wav
ffprobe -show_entries stream=sample_fmt -hide_banner mulaw.wav
# gives:
# Input #0, wav, from 'mulaw.wav':
#  Metadata:
#    encoder         : Lavf60.16.100
#  Duration: 00:00:10.80, bitrate: 384 kb/s
#  Stream #0:0: Audio: pcm_mulaw ([7][0][0][0] / 0x0007), 48000 Hz, 1 channels, s16, 384 kb/s
###### PROBLEM HERE: ######-----------------------------------------------------^^^
# [STREAM]
# sample_fmt=s16
# [/STREAM]

The sample_fmt should be s8, not s16.

Change History (5)

comment:1 by Balling, 20 hours ago

Maybe

The μ-law and A-law algorithms encode 14-bit and 13-bit signed linear PCM samples (respectively) to logarithmic 8-bit samples. Thus, the G.711 encoder will create a 64 kbit/s bitstream for a signal sampled at 8 kHz

So when decoded it must be decoded to 14 bit or since it is not supported (we do not even support standard 20 bit in HDMI spec, only 16 bit and 24, LOL!!).

Also mediainfo sees it as 16 bit, metadata.

Last edited 20 hours ago by Balling (previous) (diff)

comment:2 by Marcus Müller, 19 hours ago

Priority: normalminor
Version: unspecified6.1.1

ah, I see, that kind of makes sense. Otherwise, that field is meaningless for anything actually compressed (and not just companded/quantized).

Hm, however, is it then correct to organize it as property of {{stream}}? It seems to be a property of the decoder.

comment:3 by Marcus Müller, 19 hours ago

(oh by the way, if you don't think this constitutes a defect, please close. I wasn't sure I should close it myself since your comment started with "Maybe")

comment:4 by Balling, 18 hours ago

Are you Marcus from Gnuradio project, lol

Anyway, I was wrong https://imgur.com/a/jo9NzKh mediainfo actually shows it as 8 bit in metadata.

s16 does not mean it is 16 bit. It just means it will be decoded as s16.

comment:5 by James, 17 hours ago

Resolution: invalid
Status: newclosed

You can see that -show_entries stream=bits_per_sample reports 8, which is what's coded in the WAV header.

As Baling said, the sample format is what the decoder exports.

Note: See TracTickets for help on using tickets.