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.