[FFmpeg-devel] [Ffmpeg-devel] [PATCH] GSM-MS decoder and encoder
Thu Mar 27 17:48:27 CET 2008
Michael Niedermayer wrote:
> On Mon, Feb 19, 2007 at 11:59:14AM +0100, Michel Bardiaux wrote:
>> 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
>> 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.
> well a grep for gsm shows a hit in aiff.c so it seems it is supported in a
> non toast format currently and as there is no gsm specific code in it i would
> guess it will end with 13200 as bitrate
> anyway i wont fight about this appl the patch, i will remove the 13000 check
> when it breaks something
I was fixing agsm in mov, and this bitrate check cause init to fail for
decoding (encoding shares the function), IMHO we don't care about
bitrate when decoding.
Can I remove it ?
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
SMARTJOG SAS http://www.smartjog.com
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312
More information about the ffmpeg-devel