On Jan 7, 2011, at 16:48, Ben Allison wrote: > The issue is that silent frames compress to a very small size, and > the Ogg > packeting layer can put more than one FLAC frame into a page. So > if you > have an extended period of silence with a live or rate-limited input > stream, the client buffers may exhaust themselves before a new page > can be > put together and transmitted.
Ah, yes, I remember reading about this. It does seem like an unfortunate problem, and I would guess that both FLAC and OggFLAC have the same issue. At the very least, I don't see how OggFLAC could compress more than FLAC when using FLAC, and thus the problem should be the same in both. However, if you've been following my suggestions about flagging silence and other gaps in the broadcast content, then I think there might be a common solution to both problems. With flags for silence defined in the protocol, the streaming broadcast server would be able to alert the clients to the situation where an extended period of silence is about to occur. Maybe there would even need to be some advance notice, otherwise the flags would come too late, just like the silent frames. Seems like the streaming broadcast server could define some sort of maximum time gap, and if a future frame is going to exceed this maximum time, then a prior frame could be encoded with a flag announcing the imminent "problem" - upon which the client could simply prepare to go silent and resync. It still seems difficult, because the trailing audio right before the silent frames could end up getting trapped in a FLAC block that takes too long to arrive because it is mostly silent, but not completely silent. Perhaps a "short" block is needed so that all of the non- silent audio can be sent right away, along with a warning flag, and then the client will know to produce silence (and perhaps resync) until the super-compressed silent frames finally arrive. Unfortunately, this all seems like a significant deviation from the FLAC streaming standard, unless variable block sizes can be allowed. I must admit that I have not studied this closely, but I do seem to recall that the block can is allowed to vary under certain conditions. It might be the case that certain decoders only work with fixed block sizes, but a streaming broadcast client would obviously be a special case where support for small blocks could be mandatory without causing a huge problem. Apparently, slim has something along these lines in their stream, but I wonder whether they've fully taken advantage of the possibilities. Brian Willoughby Sound Consulting _______________________________________________ Flac-dev mailing list [email protected] http://lists.xiph.org/mailman/listinfo/flac-dev
