Subject: RE: [AVT] Generic RTP payload format for time-lined static media

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 18 Jul 2001 15:01:45 -0400

First off, I must admit I didn't follow the threads on this draft till now,
so if my issues were covered already, my apologies.

Honestly, I don't understand why the content is transferred within the RTP
at all. Unlike continuous media, which has the property that old data is not
useful if it comes too late, the timescales for this stuff are such that its
still useful if you can get it before it no longer needs to be presented,
which is probably on the order of several seconds for most everything, at
least. So, why don't you send RTP packets that contain a URL for the
content? I think you're better off fetching a JPEG using http than trying to
stream one in RTP. Beyond that, I would think this would work like rfc2833
does, in terms of conveying durations/timestamps. 

Thanks,
Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Friday, July 13, 2001 10:18 AM
> To: [email-masked]
> Subject: [AVT] Generic RTP payload format for time-lined static media
> 
> 
> Hi,
> 
> I have submitted a new draft with the title: Generic RTP 
> payload format
> for time-lined static media.
> The abstract reads
> 
>    This Internet Draft discusses an RTP payload format for time-lined
>    static media. "Time-lined static media" means static media objects
>    like pictures and text extended by timing information. Applications
>    that would benefit from such a payload format are for instance
>    slideshow streaming and streaming of subtitled video and audio. We
>    discuss the important requirements for a payload format 
> and propose a
> 
>    specification that suits those requirements.
> 
> Untill the draft is available in the IETF directory you can find it
> here:
> http://standards.ericsson.net/westerlund/draft-westerlund-avt-
rtp-static-media-00.txt

Please read the draft and comment on it. I also hope to have the
possiblity to present and discuss it in London.

Regards

Magnus Westerlund

Audio Technology, Ericsson Research
----------------------------------------------------------------------
Ericsson Radio Systems AB  | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
http://www.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
http://www.ietf.org/mailman/listinfo/avt

---

From: Ross Finlayson <[email-masked]>
Date: Wed, 18 Jul 2001 16:51:11 -0700

At 12:01 PM 7/18/01, Jonathan Rosenberg wrote:
>stream one in RTP.

I think that - like many other uses of RTP - this proposed payload format 
makes the most sense for multicast sessions - especially large-scale 
multicast sessions.

My favorite potential application here is an Internet 'radio station' that 
streams synchronized lyrics (and other song-specific info) for each song 
that it streams.  Although that particular application might be able to use 
the RFC2793 payload format ("text-based conversation"), the problem of 
transporting "time-lined static media" (to use the authors' wording) seems 
to be a general one, and the "building block/profiles" approach that the 
authors are taking seems like a sound one.

         Ross.