Hi,<div><br></div><div>Thanks to all for your reply to the previous question.</div><div><br></div><div>Another question is, is it possible to make CELT scalable? For example, if I ran the encoder to encode a 320kbps bitstream, is it possible to split the 320kbps into a valid 160kbps bitstream and the residue? This way, I can send the 160kbps packet first, and then if the network condition allows, the residue will be send next.</div>
<div><br></div><div>Thanks</div><div>Liz</div><div><br></div><div><br><div class="gmail_quote">On Wed, Aug 22, 2012 at 5:14 PM, Benjamin Schwartz <span dir="ltr"><<a href="mailto:benjamin.m.schwartz@gmail.com" target="_blank">benjamin.m.schwartz@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wed, Aug 22, 2012 at 5:09 PM, Gregory Maxwell <<a href="mailto:gmaxwell@gmail.com">gmaxwell@gmail.com</a>> wrote:<br>
> Flac can have latency as low as you like— e.g. you can code 64 sample<br>
> frames. You do lose compression efficiency in doing this, however.<br>
<br>
</div>For more info on how to do this see encoder_set_blocksize:<br>
<a href="http://flac.sourceforge.net/api/group__flac__stream__encoder.html#ga21" target="_blank">http://flac.sourceforge.net/api/group__flac__stream__encoder.html#ga21</a><br>
<br>
However, for low-latency lossless audio, you may actually want use<br>
uncompressed PCM (like WAV). With a lossless compressor like FLAC,<br>
there is no guarantee that the audio will be made smaller (it can even<br>
become larger), so you will need enough bandwidth to send uncompressed<br>
audio anyway. if you rely on the compression to work, then your<br>
system will break on the occasional incompressible block. For<br>
low-latency lossless audio, compression only makes sense if you have a<br>
lot of available peak bandwidth, but for some reason (e.g. ISP quota)<br>
are trying not to use it.<br>
</blockquote></div><br></div>