Icecast dev - Apr 2008 - [PATCH] kate streams for libshout svn and icecast svn

ogg.k.ogg.k at googlemail.com wrote:
> Hi,
> 
> ACK/NAK on any of those two points (kate support patches and status of
> skeleton support) ?
> 
Brendan was the one to working on libshout, but he may be away 
currently.  I can check over it after the dir.xiph.org and icecast 
updates I have are done.  I have not checked over the Kate parts for 
icecast yet but I don't have a problem with them in principle post 2.3.2.

karl.

> Brendan was the one to working on libshout, but he may be away
> currently.  I can check over it after the dir.xiph.org and icecast
> updates I have are done.  I have not checked over the Kate parts for
> icecast yet but I don't have a problem with them in principle post
2.3.2.
OK, thanks for the note.

Cheers

Is SVN Icecast having a problem with Skeleton streams?  While unlikely
to affect Vorbis, this may be a serious problem with Theora, as all
the new Theora streams are encoded with an added Skeleton.

I haven't been able to test recent Icecast yet (and I promised I
would), so if possible I'd like to know what is the status with
Skeleton support (or lack thereof).

-Ivo

> And there they are, with added skeleton support.
And it got stuck in the icecast-dev moderation queue due to size, fyi.

ogg.k.ogg.k at googlemail.com wrote:
> And there they are, with added skeleton support.
> While the Kate stuff is tested on various files, the skeleton stuff is
> lightly tested
> only (on a 7 stream file). Both are rather simple anyway.
> 
> The only thing is I'm not too sure whether the timestamps in the
> skeleton headers
> should be modified at all for every connection, I just leave them as
> is, but one of
> the header fields is a "start time", so... Anyway, it's
ignored by
> everything I know
> of, so maybe only a theoretical issue anyway.
Can we get confirmation on the player parsing skeleton streams without 
issue and are there any cases that should be considered where an 
incoming skeleton stream should be filtered for a player connection? If 
not then I have no problem with it going in for 2.3.2.


karl.

> Can we get confirmation on the player parsing skeleton streams without
> issue and are there any cases that should be considered where an
> incoming skeleton stream should be filtered for a player connection? If
> not then I have no problem with it going in for 2.3.2.
I've tried only with xine, with svn icecast and libshout's example
client.
The stream was skeleton x1, theora x1, vorbis x1, kate x4, and played
fine. My copy of vlc was broken at the time, but once it's back on its
feet I'll give it a try with vlc as well.
I didn't think of filtering skeleton streams for those players that do not
grok it - is it possible to tell which players are streaming ? Not sure if
it would be a good idea anyway, if icecast/libshout releases are far
between. Is there any system for players to send the type of things they
can use (eg, Accept: audio/vorbis, or something) ? That could be an
easier way for icecast to know what to send and what not.