[Flac-dev] Synchronizing a streaming client to the server Was: Idea to possibly improve flac?
brianw at sounds.wa.com
Fri Jan 7 18:12:51 PST 2011
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.
More information about the Flac-dev