Icecast dev - Apr 2008 - Caching current events for new listeners

Hi,

I'm trying to work out how one would go about caching
"interesting" packets
from a stream to be sent to newly connecting listeners. At the moment, for, eg,
Theora and Vorbis, the only interesting packets are the recent ones (up to a
keyframe for theora), but, in my case, I can have old packets be still active
while newer packets are obsolete, as packets are sorted by their presentation
time, but may have arbitrary timespan.

My codec handler keeps track of those packets, but I can't find how to send
them on connection. My guess was to try to piggyback onto the code that
sends headers, but that relies on an already built set of headers, and it does
seem like a big waste of resources to continually update centrally this list for
my case, rather than get it from the codec only when a new listener connects.

Any pointers on the best way to do this ?

Cheers

ogg.k.ogg.k at googlemail.com wrote:
> Hi,
> 
> I'm trying to work out how one would go about caching
"interesting" packets
> from a stream to be sent to newly connecting listeners. At the moment, for,
eg,
> Theora and Vorbis, the only interesting packets are the recent ones (up to
a
> keyframe for theora), but, in my case, I can have old packets be still
active
> while newer packets are obsolete, as packets are sorted by their
presentation
> time, but may have arbitrary timespan.
> 
> My codec handler keeps track of those packets, but I can't find how to
send
> them on connection. My guess was to try to piggyback onto the code that
> sends headers, but that relies on an already built set of headers, and it
does
> seem like a big waste of resources to continually update centrally this
list for
> my case, rather than get it from the codec only when a new listener
connects.
> 
> Any pointers on the best way to do this ?
you can't keep them in the main queue because you are subject to the 
queue size cutoff so you either keep this within the per codec handle 
structure (codec list) and/or in the block for the header pages (via the 
associated pointer).  The sending handlers are not really codec aware 
but they do notice a change in headers.

karl.

> you can't keep them in the main queue because you are subject to the
> queue size cutoff so you either keep this within the per codec handle
> structure (codec list) and/or in the block for the header pages (via the
> associated pointer).  The sending handlers are not really codec aware
> but they do notice a change in headers.
Yes, but that's the problem I'm facing:

- if I keep them in the codec specific struct (which is what I'm doing now),
I can't request them when a new listener connects, as I don't know when
this happens from the format_ogg.c code

- if I keep them (and update them as streaming goes on) in the headers list,
then send_ogg_headers will continuously stream them out, but I don't want
that since that'll get pushed to all listeners, and they'll have already
gotten
those as normal streaming progresses.

Cheers