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
_______________________________________________
Icecast-dev mailing list
Icecast-dev@...
http://lists.xiph.org/mailman/listinfo/icecast-dev

[Karl Heyes]

ogg.k.ogg.k@... 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.



_______________________________________________
Icecast-dev mailing list
Icecast-dev@...
http://lists.xiph.org/mailman/listinfo/icecast-dev

> 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
_______________________________________________
Icecast-dev mailing list
Icecast-dev@...
http://lists.xiph.org/mailman/listinfo/icecast-dev

[Karl Heyes]

ogg.k.ogg.k@... wrote:

> - 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.

There are certain things that could be done to help the situation, I'm
not sure which would be best in your particular case but the current
sync_point setting could be turned into a general bitmask flags, where
sync point is just one and you can have codec specific allocations of
those flags.

Also the check_buffer routine is called before the send_to_listener.
It's used to populate data from intro/fallback files or progress through
the queue. You could set a special check buffer handler that checks the
above refbuf_t flags. It's possible to create a per-client refbuf_t
within there that hooks back into the queue.

karl.

_______________________________________________
Icecast-dev mailing list
Icecast-dev@...
http://lists.xiph.org/mailman/listinfo/icecast-dev

Thanks for the pointers, I'll have a look at those.

Cheers
_______________________________________________
Icecast-dev mailing list
Icecast-dev@...
http://lists.xiph.org/mailman/listinfo/icecast-dev