[Ffmpeg-devel] [PATCH] GSM-MS decoder and encoder
Mon Feb 19 11:59:14 CET 2007
Michael Niedermayer wrote:
> On Sat, Feb 17, 2007 at 03:42:52PM +0100, Michel Bardiaux wrote:
>> Michael Niedermayer wrote:
>>> 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
> 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
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
T +32  2 790 29 41
F +32  2 790 29 02
E mailto:mbardiaux at mediaxim.be
Vorstlaan 191 Boulevard du Souverain
Brussel 1160 Bruxelles
More information about the ffmpeg-devel