[FFmpeg-devel] [PATCH] GSM-MS decoder and encoder

Michel Bardiaux mbardiaux
Mon Apr 28 17:16:21 CEST 2008


Michael Niedermayer wrote:
> On Mon, Apr 28, 2008 at 01:53:56PM +0200, Michel Bardiaux wrote:
>> Diego Biurrun wrote:
>>> On Fri, Apr 25, 2008 at 12:10:06PM +0200, Michel Bardiaux wrote:
>>>> [...]
>>> While you guys are at it, there are still a couple of samples that do
>>> not work in ffplay:
>>>
>>> http://samples.mplayerhq.hu/A-codecs/msgsm/levis.avi
>> ffmpeg -i levis.avi -vn -acodec pcm_s16le -y levis.avi.wav
>> FFmpeg version SVN-r13009, Copyright (c) 2000-2008 Fabrice Bellard, et al.
>>    configuration: --enable-libmp3lame --enable-gpl --enable-x11grab 
>> --enable-libgsm
>>    libavutil version: 49.6.0
>>    libavcodec version: 51.56.0
>>    libavformat version: 52.13.0
>>    libavdevice version: 52.0.0
>>    built on Apr 28 2008 12:14:17, gcc: 4.1.2 20061115 (prerelease) 
>> (Debian 4.1.1-21)
>> Input #0, avi, from 'levis.avi':
>>    Duration: 00:00:44.83, start: 0.000000, bitrate: 352 kb/s
>>      Stream #0.0: Video: indeo3, yuv410p, 152x116,  6.00 tb(r)
>>      Stream #0.1: Audio: libgsm_ms, 44100 Hz, mono, 71 kb/s
>> Output #0, wav, to 'levis.avi.wav':
>>      Stream #0.0: Audio: pcm_s16le, 44100 Hz, mono, 705 kb/s
>> Stream mapping:
>>    Stream #0.1 -> #0.0
>> [libgsm_ms @ 0x8451ff0]Sample rate 8000Hz required for GSM, got 44100Hz
>> Error while opening codec for input stream #0.1
>>
>> IMHO the codec should not second-guess the demuxer, 
> 
> but libgsm.c does exactly that ...

Because I was requested to make it so. My position was that only the 
strictly-according-to-spec 13000 should be allowed, anything else to be 
corrected by the demuxer. But that was not accepted, people want 
something like "Mmm, the demuxer says bitrate 0, but it really must mean 
13000, so I will assume that".

> 
> 
>> its the latter that 
>> should fix things if the file is obviously corrupted (which this one 
>> is!). 
> 
> I see nothing corrupt on the file
> 
> 
>> That is, at the end of get_wav_header (proper patch when there is 
>> agreement of the ways and means). Theoretically there is no maintainer 
>> for riff.c but since Michael is maintainer for the avi muxdemux I guess 
>> he is for riff.c too (should I correct MAINTAINERS?)
> 
> Yes i mainain riff.c, feel free to add me to the list if you like ...
> 
> 
>> And whether the demuxer or the codec changes the sample rate, a warning 
>> should be issued. OK?
> 
> Print as many warnings as you like :)
> but please dont reject streams at random, 

It is *NOT* at random. The spec is very clear: the sample rate for GSM 
is 8000. Any other value in the RIFF headers is simply wrong and hints 
that the encoder has screwed up.

> patch below fixes this file and
> i suspect others as well, i will apply it in 24h unless you object.

The change was submitted for review and you didn't object... But if you 
insist on a quick-and-dirty fix for all those malformed files, patch 
attached for your consideration. But consider the consequences:

FFmpeg version SVN-r13009, Copyright (c) 2000-2008 Fabrice Bellard, et al.
   configuration: --enable-libmp3lame --enable-gpl --enable-x11grab 
--enable-libgsm
   libavutil version: 49.6.0
   libavcodec version: 51.56.0
   libavformat version: 52.13.0
   libavdevice version: 52.0.0
   built on Apr 28 2008 12:14:17, gcc: 4.1.2 20061115 (prerelease) 
(Debian 4.1.1-21)
Input #0, avi, from 'levis.avi':
   Duration: 00:00:44.83, start: 0.000000, bitrate: 352 kb/s
     Stream #0.0: Video: indeo3, yuv410p, 152x116,  6.00 tb(r)
     Stream #0.1: Audio: libgsm_ms, 44100 Hz, mono, 71 kb/s
Output #0, wav, to 'levis.avi.wav':
     Stream #0.0: Audio: pcm_s16le, 44100 Hz, mono, 705 kb/s
Stream mapping:
   Stream #0.1 -> #0.0
[libgsm_ms @ 0x8452010]Sample rate 8000Hz required for GSM, got 44100Hz, 
fixed
[libgsm_ms @ 0x8452010]Bitrate 13000bps required for GSM, got 71656bps, 
fixed
Press [q] to stop encoding
size=    3861kB time=44.8 bitrate= 705.6kbits/s
video:0kB audio:3861kB global headers:0kB muxing overhead 0.001113%

If we do

ffmpeg -i levis.avi -an -vcodec copy vidonly.avi

we get a file size that indicates the audio stream in levis.avi occupies 
401066 bytes, or 6170 MSGSM blocks, or 1974400 samples, on 45" that 
means 43875Hz, hence it is *really* 44100Hz, the encoder fed frames to 
the library without rate conversion. Do we really want to accept such a 
file?

> 
> Index: libgsm.c
> ===================================================================
> --- libgsm.c	(revision 13005)
> +++ libgsm.c	(working copy)
> @@ -41,18 +41,6 @@
>                 avctx->channels);
>          return -1;
>      }
> -    if (avctx->sample_rate != 8000) {
> -        av_log(avctx, AV_LOG_ERROR, "Sample rate 8000Hz required for GSM, got %dHz\n",
> -               avctx->sample_rate);
> -        return -1;
> -    }
> -    if (avctx->bit_rate != 13000 /* Official */ &&
> -        avctx->bit_rate != 13200 /* Very common */ &&
> -        avctx->bit_rate != 0 /* Unknown; a.o. mov does not set bitrate when decoding */ ) {
> -        av_log(avctx, AV_LOG_ERROR, "Bitrate 13000bps required for GSM, got %dbps\n",
> -               avctx->bit_rate);
> -        return -1;
> -    }
>  
>      avctx->priv_data = gsm_create();
>  
> 


-- 
Michel Bardiaux
R&D Director
T +32 [0] 2 790 29 41
F +32 [0] 2 790 29 02
E mailto:mbardiaux at mediaxim.be

Mediaxim NV/SA
Vorstlaan 191 Boulevard du Souverain
Brussel 1160 Bruxelles
http://www.mediaxim.com/
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gsm-3.pat
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080428/5ec2f4f7/attachment.txt>



More information about the ffmpeg-devel mailing list