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

[Michel Bardiaux]

Michael Niedermayer wrote:
> Hi
> 
> On Sat, Feb 17, 2007 at 03:42:52PM +0100, Michel Bardiaux wrote:
>> Michael Niedermayer wrote:
>>> Hi
[snip]
>>>
>>> is 13000 exactly correct isnt it 13200 for CODEC_ID_GSM?
>> Yes and no. The last 4 bits of each frame are not actually used, they
>> come on stage only because we (both libgsm and lavc) use a byte-oriented
>> API, and files made of bytes. They should be considered as container
>> overhead in TOAST files, hence not part of the codec bitrate.
> 
> but with this argumentation we would have to subtract the padding bits from
> mpeg from the bitrate too and thats something we dont 

I think you're talking codec-level padding here, but I wrote of 
container overhead.

> also it would cause
> problems for containers which expect the bitrate well to be the bitrate of
> what they get, not to be slightly less due to some padding bits they dont
> know about ...

AFAIK currently only some MS containers (AVI, WAV) accept GSM, and then 
only MS-GSM, which does not have the problem. The only container for 
non-MS-GSM is TOAST (currently not implemented) and that one knows about 
the 4 extra bytes.

The only reason the muxer 'gets' the padding bits, is because the muxing 
API is byte-oriented, which is a very useful but not 100% correct 
assumption.

There is also a pragmatic reason to avoid stating 13200 as bitrate for 
non-MS-GSM: because it is not intuitive, most users will end up asking 
on -user why it is not the 13000 that everyone expects. Do we need one 
more FAQ?


> 
[snip]


-- 
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/