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@xiph.org'
containing only the word 'unsubscribe' in the body. No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.