[xiph-rtp] Re: [Speex-dev] new RTP development list

[Phil Kerr]

Hi Tor,

Regarding metadata I was talking to Ralph earlier today about the new 
Wiki pages and I think we are roughly in sync with ideas, here's what 
we were talking about:

>
>> Ok, I've seen your comments about the metadata streams.  There are
>> essentially three choices, using a custom metadata packet type (makes
>> the stream handling slightly more complex as you will have to
>> filter-out packets, but everything is together), RTCP (which the IETF
>> may be slightly iffy about but if the bandwidth used to send the
>> messages is small it might be ok) or using a completely separate RTP
>> stream.
>
> Yeah. I don't really like overloading writ for subtitles. Our general
> idea was always to do RDF+dublin core based metadata. It's just that
> the XML encoding kind of sucks, so I kept waiting for that to get 
> better.
> I've been waiting 3 years now. :)
>
> If I had to just do something that worked, I'd just do length-encoded
> string triplets. Not standard at all, but straightforward RDF.
>
> CMML is another option; I believe CSIRO is working on an RTP format.
>
>> Option 3 might require more thought as metadata could be part of
>> OggWrit.  I know there was a RTP text I-D being worked on and it might
>> be best to see if we can piggy-back on this instead of re-writing a
>> fresh I-D (unless it is needed).
>
> Yeah, I'd be happy to adopt something else, assuming it doesn't suck.

So, for Vorbis-RTP, the plan seems to be use only one set of codebooks 
for the session duration, making it possible to set them via SDP.

In -03 I described a basic mechanism for codebook caching which should 
be ok, but please have a look and rip it apart for any potential 
problems.

I think the biggest issue is how to handle metadata.  To an extent 
option one I described above (in stream with a different packet-type) 
would make it more compact.  Option two is probably not the best but it 
does use an existing infrastructure (RTCP) so it is easy to implement.

If option three seems the best way forward should we make this 
something generic across all of the Xiph bitstreams, so it can be 
reused?

Another question is how reliable does the the transport of the metadata 
need to be?  It's not as vital to stream decoding as the codebooks so I 
don't think it needs to be transported over a reliable connection such 
as TCP.

-P

ps.  Minor point; should the reply-to field be set to xiph-rtp?  I've 
been caught out a few times replying to a list and it's gone to one 
person only by mistake :)


On 20 Oct 2004, at 16:27, Tor-Einar Jarnbjo wrote:

> Tirsdag, 19 oktober 2004, skrev Ralph Giles :
>
>> So, like I said, join the list if you want to help hammer out the
> details.
>
> Yeah, I joined the list, but there was no traffic there, so I thought
> I'd ask. The preffered solution for me would be something like this:
>
>
> - Replace the identification and comment header with appropriate
> SDP fields. Most attributes from these headers have a matching standard
> SDP field anyway, the rest can be covered by Vorbis specific extension.
>
>
> - Allow or recommend a separate meta data RTP stream (CMML based
> or whatever) to minimize the need for chaining. At the moment, Ogg
> chaining is mostly used to allow pseudo in-stream comment headers.
>
>
> - Define a separate data source for the setup header in the SDP 
> descriptor.
> For unicast streams, this may just as well be a HTTP URL, for 
> multicast,
> a separate RTP stream should be continuously streaming the setup
> header, allowing the client to join and leave the multicast session
> as required.
>
> I already implemented a rough proof-of-concept client using this
> approach for unicast streams. I didn't add RTSP or SDP support, so
> the client is taking some data from a provided configuration file,
> some data is exchanged with the server using a proprietary TCP based
> protocol for session control and some stream attributes are hard
> coded in the client, but at least the RTP stream seem to work and
> the setup header is loaded from the configured HTTP URL. If you're
> interested, you can take a look here:
>
> http://www.j-ogg.de/rtp/index.html
>
>
> Tor
>
>
> _______________________________________________
> xiph-rtp mailing list
> xiph-rtp at xiph.org
> http://lists.xiph.org/mailman/listinfo/xiph-rtp
>