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

Michel Bardiaux mbardiaux
Fri Mar 28 14:26:54 CET 2008


Baptiste Coudurier wrote:
> Michael Niedermayer wrote:
>> Hi
>>
>> On Mon, Feb 19, 2007 at 11:59:14AM +0100, Michel Bardiaux wrote:
>>> 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.
>> 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 ?
> 
Oops, forgot I am maintainer for libgsm!

Since bitrate is also irrelevant for encoding, what about this?

-- 
Michel Bardiaux
http://www.mediaxim.com/
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 13000.pat
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080328/1712b5ab/attachment.txt>



More information about the ffmpeg-devel mailing list