[xiph-rtp] Lots of proposals

[Luca Barbato]

I spent the day with the rest of the oms group (streaming.polito.it if
you don't know already) thinking and rethinking about some issues.

That is a short memo, looks like we got to similar conclusions in
different fields.

The first part of brainstorming was about the overhead of not allowing
chaining in rtp and the result that the major overhead is about the fact
in most cases you have more (x2) ports open since you have to add rtp
streams; in certain situations it is a non issue, in certain could if
you don't have enough resources

Since I'd like to have the rtp describing ONLY rtp in vorbis and use it
as baseline for other rfcs to provide or define better extended features
(like outband transmission that require other protocols)

Here follows the summary:


####
The first suggestion was developed by Federico Ridolfo and is about
codebook (and Configuration and metadata) retrasmission and packet skips.

It works that way:

- If the codecbook(and the other metadata) aren't available the client
have to skip to the next packet untill they are received correctly.

- The 3 start packet will be resent each N time with the same timestamp eg:

Time 0 Configuration Codebook and Metadata sent
Time 1 Raw sent
..
..
Time N Configuration Codebook Metadata Raw sent
Consider that each raw packet is sent every 20ms, once you reach 20Nms
you send the 3 start packet again and the raw one.

The way to discover if you have or not have the right settings and you
have to skip could be the usual hash or a codebook id mapping in sdp (in
that case the tag field can be shorter and be an incremental number)

That solution supports part of the chaining features and could be used
on every scenario w/out issues.


###
Another issue was about using the Marker bit to delimit syncpoints and
how to use timestamps to support some editlist features

###

The last piece was about minimizing the information to be sent inband,
the metadata packet and the configuration packet could be replicated in
the sdp (it depends mostly on the metadata content but that is another
issue). Everything that could fit in the sdp should stay there since on
the multicast/conference scenario that data will be presented to the
client joining for sure and it won't be any need to retransmit it.
That could be one of the famous early optimization but start thinking
about that could be useful or not

###
The other discussions were about ways to support Offband transmissions
using RTSP and mappings using SDP but those don't belong to the rtp
draft I guess.


Those features won't require other protocols and should support quite
well the following scenarios:

° conference/multicast

° playlist on demand

° webcast with or without live and pseudo live feeds

° adaptive changes in the bitstream


Tomorrow I'll write something better after my exam.

lu

-- 

Luca Barbato

Gentoo/linux Developer		Gentoo/PPC Operational Leader
http://dev.gentoo.org/~lu_zero