No subject

one of the possible streams will be chosen, either by round-robin, some
other deterministic method, or by geographic or netographic proximity.

The question for implementation here is whether to implement this at the 
directory server level or somewhere else.  In one scenario (this is similar
to how the Shoutcast directory operates), the relay streams report to
the directory server directly and the directory is responsible for 
authenticating and grouping this information.  In a different scenario,
the original server (or whatever owns the directory entry) is responsible
for reporting on it's relays.

The latter scenario makes more sense, in my opinion, and supports other
types of media entries better.  Putting the responsibility on the owner
of the entry for tracking its mirrors seems correct.

Note that a 'professional' stream might handle this case in a different way,
by having relays hidden behind a multi-host dns entry, in the same way
that webservers are often load balanced.  In this situation, the stream
would appear as Type 1.

Type 3: Single stream with multiple bitrates
--------------------------------------------

A broadcaster may offer a stream at a variety of bitrates for technolgies
that don't support transparency in this regard.  Typical broadcasters
may offer both a high and low bitrate version of their content.

In icecast terminology, we call the the group a stream and each
bitrate an instance of the stream.  This terminology is reflected in
configuration files for ices.

It is important to group these instances under a common entry, since they
logically represent one stream.  Like a mirror/relay, this is just an
alternative version of the same data, not new data.  This should be handled
in much the same was as mirrors.  As much as possible the users should
be given streams automatically, and in all cases this should appear to the
users as alternatives for one stream, and not appear as multiple distinct
streams.

In the case where someone mirrors this type of broadcast, they may only mirror
parts.  A mirror is an alternative location for an instance of a stream.  A
stream is broken up into it's instances (alternative formats and bitrates
for examples), and these instances may have mirrors.

This also speaks for the owner responsibility model for tracking mirrors.
It would be fairly easy to have the original server track this information,
but tracking it on the directory would involve some searching and grouping.
The owner of the stream can know more about the connectivity of a mirror
much easier than the directory can.

Type 4: Multiple streams
------------------------

Many broadcasters will want to offer multiple distinct streams to the public.

This should be handled differently than many streams of types 1, 2 or 3.
It is sometimes useful to know what other streams a particular broadcaster
offers.  If one really enjoys a particular stream, one might likely enjoy
another from the same broadcaster.  

These should be in a logical group, even if such a grouping is never offered
to a user.  It is also likely that these streams will be maintained in the
directory as a group, and not as a number of single stream entries.

All the groups apply from the previous three cases.  You might have multiple
streams, each with multiple formats and bitrates, and each of those with
alternative locations.

Type 5: Directories of streams
------------------------------

This case is likely to be rare, but two directory systems might become
part of a third system.  In this case, one might want to preserve
which directory each set of streams came from.  This type is also
likely to maintained in a much different way.  The directory itself
will probably maintain directory level entries.

Current state
-------------

The current directories only support Type 1 and Type 2 entries.  Considering
common Type 3 and Type 4 are, this is a serious deficiency, and must
be addressed in the new directory system being proposed.

All types of entries must be gracefully handled, and only type 5 can
be left to some manual or custom handling.

--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to 'icecast-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.