[vorbis] streaming: some idea's

[Kristoff Bonne]

Greetings,

A couple of weeks ago, there was here a discussion about streaming. Here
is two things that I would like to add to
the discussion: meta-streaming and control-streaming. (Althou I do not
think my ideas are that new)

* First metastreaming:
If you look at DVB (Digital Video Broadcasting), one of nice features
(apart from it being a European standard ;-)) is the existing of a
meta-stream.

On DVB, the meta-stream (among others)
- Contain information on what audio-stream(s) is/are couples to what
video-stream.
- And what 'CA' (Conditional Access) system is used for a certain stream.
- But, it also adds the notion of 'bouquets': groups of programs that are
bundled together, and that can span multiple transponders on a satellite
or on multiple satellites (at the same satellite-position or a different).

Perhaps, it would be good idea to see if a meta-stream is possible/desirable
for vorbis, and what we can put in it.

I would propose to make it as open as possible.
Possible information to put in it could be:
- Alternative bitrates.
"This content is also available at these bitrates, and these are the
methods (read: URLs) to retrieve them."
(Could be used by the player to 'upstep' or 'downstep' the stream based
on the quality of the network connection).

- Alternative formats:
"This content is also available in alternative formats (e.g. MPEG, real,
WMT), and these are the methods to retrieve them".

- Alternative distribution means:
"This content is also available at other distribution means":

This can be alternative no-network technologies like FM, DAB ('Digital
Audio Broadcasting'), or DVB for people who have a radio, DAB or DVB-card
in their PC, or (in the future) UMTS-services.

Also interesting would be directing to IP-Multicast services (as I can
very well image a situation where ADSL or cable-user will get different
pricing-scemes for IP-multicast traffic compaired to IP-unicast) or
IPv6-services (for the inherent QOS-technologies of IPv6).

Another idea is this:
ISPs like to keep as much traffic 'local', this to cut down on cost of
their 'internet backbone-connections'.

One of the ways to do this is installing local caches for certain
streaming-content. Nowtheys, there are even 'unicast-to-multicast' caches
that take a single unicast stream for the internet and re-distribute is as
one of multiple IP-multicast streams in the local network.

The question is: how do you get your users to tune into your cache and not
into the 'original':
I see three ways:
- Transparent caching: 'intercept' the outgoing streaming-request from the
user to the streaming-server.

- A second methode would be where the original server can sent out
'alternative metastream' information to the player, which would 'direct'
it to possible 'local caches' throu-out the net. (the caches would then
have the possibility to accept/reject request coming in from the players,
or do this with a certain 'priority' compaired to a value set by the
'original' server.
This could be higher in the case where the cache receives a request from
one of her 'local users'.
This could be lower in the case where the cache acts as a sort of
'backup'-streaming server for the original server. 

- A thirth possibility is where the local cache would sent out its
meta-streaming information using IP-multicasting using a 'network-local'
IP-multicast address. (usually, this is the 239.x.y.z. address).

The streaming-server would the 'direct' the player to this meta-stream (if the
player can actually 'hear' it), but -as traffic to network-local addresses are
'local to the network' (hence its name), the player would only "hear" the
streams that are relevant to it.

* Control-streaming:
This something that already exists in other streaming-system: a 'control
stream' from the player to the server.

This stream could contain information
- about the quality of the stream
- re-request 'lost' packets. (E.g. for IP-multicast streams or streams
received over one-way wireless systems like satellite)

- request a step-up or step-down of the bitrate of the stream (which could
actually mean change of group-IP-address for IP-multicast streaming).
- 'alternative-source-reachability-information'.
If a server is about to get saturated, it would be nice if it could direct
its 'listerens' to other servers (local caches, backup-servers, ...) while
it is playing. But, (e.g. when re-directing to IP-multicast streams or a
local cache), it is not always sure that the player can actually 'reach'
the new source.

One things to concider:
When a player connects to a 'local cache', where should the control
stream go to? To the cache or to the original server?

Just some basic ideas.
All comments welcome!

Cheerio! Kr. Bonne.

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-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.