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 ? -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA SMARTJOG SAS http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA Phone: +33 1 49966312