There is a hack fix that won't break the standard. Disable constant subframes and fixed subframes on the encoding end. 100% compatible. Your going to be using all that bandwidth most of the time anyways, and when it goes down temporarily, that could actually cause a problem at the network level depending on the fancyness of your QoS and other routing razzle dazzle.
Here is the other hack so that you don't get a logjam in the Ogg layer. https://github.com/oneman/libflac/commit/67e13364032404ebc1837af143fdd1cd81786c3a -David On Fri, Jan 7, 2011 at 9:12 PM, Brian Willoughby <bri...@sounds.wa.com> wrote: > > 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 > Flac-dev@xiph.org > http://lists.xiph.org/mailman/listinfo/flac-dev > _______________________________________________ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
