[Vorbis-dev] Re: Streams with block sizes 4096 and 8192

[罗 强]

>Message: 4
>Date: Wed, 2 Mar 2005 16:40:35 +1100
>From: Michael Smith <mlrsmith at gmail.com>
>Subject: Re: [Vorbis-dev] Streams with block sizes 4096 and 8192
>To: "kiran.aral at wipro.com" <kiran.aral at wipro.com>
>Cc: vorbis-dev at xiph.org
>Message-ID: <3c17372105030121401dc18284 at mail.gmail.com>
>Content-Type: text/plain; charset=US-ASCII
>
>On Wed, 2 Mar 2005 11:01:42 +0530, kiran.aral at wipro.com
><kiran.aral at wipro.com> wrote:
>> 
>> Hello All,
>> 
>> As Kumar mentioned, Block size of 8192 would definitely increase memory
>> requirements for decoder implementation. Thanks Kumar, for mentioning
>> this in this forum. I also emphasize the low memory requirements and
>> less complexity on the decoder side would increase Vorbis' presence in
>> audio market especially in portable player market.
>> 
>> I also suggest Vorbis project to draft an amendment by removing 4096 and
>> 8192 block sizes for Vorbis implementation on embedded platforms
>> provided there are no definite advantages.
>
>If we did remove 8196 (and I'm not saying we would), we _certainly_
>wouldn't even consider removing 4096 - that's in wide use, and has
>been for some years. Removing it would break a lot of files that users
>are happily playing at the moment.
>


But I think, in stereo, if 4096 block size supportted, another 3K words(32 bits/word) for workbuffer 
and another 2K words(32 bits/word or 16 bits/word) for window table, it is a not acceptted in portable
audio player. then, I also suggest not supportting 4096 and 8192 block sizes.



>I don't think removing 8196 is really something we'd want to do either
>- as a concession to limited-memory devices, the final format
>specification (as finalised when we did the libvorbis 1.0 release)
>removed several larger block sizes that had previously been permitted
>(I think these were 16k, 32k, and 64k).
>
>I don't think we want to retroactively change the vorbis format (for a
>future "vorbis 2", we'd certainly be willing to consider any sort of
>changes, though).
>
>Mike
>