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/