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

From: Magnus Westerlund <[email-masked]>
Date: Fri, 13 Jul 2001 16:18:17 +0200

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

---

From: Ross Finlayson <[email-masked]>
Date: Fri, 13 Jul 2001 19:03:40 -0700

>for time-lined static media.
...
>possiblity to present and discuss it in London.

Overall, I like this approach a lot.  For a while this working group has 
been considering how to transport time-based 'metadata' over RTP, and the 
general approach you're taking - a common payload format defined, along 
with various application-specific 'profiles' - seems like a good way to do 
this.  Personally, I'm interested in using something like this to transport 
"ID3" tags <http://www.id3.org/>; these are commonly used to describe 
meta-data for music tracks (and also allow for features like 
time-synchronized lyrics).

Some specific comments on your proposal:

- Section 4 - Requirements:
         - Multicast capabilities The payload format specification SHOULD
         allow streaming of time-lined static media objects using 
multicasting.

I'd make this a MUST, not SHOULD.

- Section 5.1 - RTP Header Usage:
         Timestamp: The timestamp is used for identifying the time when
         the object shall be used by the receiver(s). The timestamp MUST
         be identical for all packets being part of the same object, i.e. the
         timestamp is used for binding packets to the correct object.
         If two different objects are going to be used at the same time,
         they MUST have different timestamps.

This last requirement seems unnecessary.  What's wrong with having two or 
more objects with the same start time?  There seems to be no reason to 
disallow this.

- Section 8.1: Confidentiality
         To achieve confidentiality of the transported media, all RTP payload
         bits MUST be encrypted.

This wording implies that the use of encryption is manditory with this 
payload format, which is not what you really meant here, right?

         Ross.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 16 Jul 2001 09:27:34 +0200

Hi Ross,

Good that you like the proposal. I definitely hope we all can create progress in this
issue, with an open and healthy discussion. See comments to your comments inline.

> I'd make this a MUST, not SHOULD.

Yes, I agree it is a MUST.

> more objects with the same start time?  There seems to be no reason to

The current draft overloads the timestamp field to also be object identifier for
reassemble of fragmented objects. If you have an object fragmented to 5 packets, they all
carry the same timestamp. This allows the receiver to now that these five packets belong
to the same object. If you would allow multiple objects within the same RTP stream to have
the same timestamp, you will have to use something else for identifying the object each
packet belongs to. The Object Identifier header in the draft is not intended to be used
for this.

> payload format, which is not what you really meant here, right?

No, I will rephrase the sentence. I am only concerned that if you do encryption, all
payload bits should be encrypted. Perhaps a MUST is a little to strong and a SHOULD is
more appropriate. I and my coauthors will consider this.

Regards

Magnus Westerlund

---

From: Ross Finlayson <[email-masked]>
Date: Mon, 16 Jul 2001 16:16:05 -0700

At 12:27 AM 7/16/01, Magnus Westerlund wrote:
> > This last requirement seems unnecessary.  What's wrong with having
> > two or more objects with the same start time?  There seems to be no
> > reason to disallow this.
>
>reassemble of fragmented objects.

This seems really ugly.  If we're designing a new payload format, we should 
try to make it as architecturally clean as we can, and not overload fields 
unnecessarily.

>  If you have an object fragmented to 5 packets, they all
>to the same object.

The usual way that RTP payload formats handle fragmentation over successive 
packets is for the payload-format-specific header to contain specific 
fields (often, just fragment start/end bits) that indicate whether or not 
the RTP payload is an incomplete fragment.  In your proposed format, you 
could do this by defining a special "Fragment Header" (with its own "Hd. 
type") to indicate that all following bytes are part of a fragment.  Or you 
could reserve two bits in your 8-bit "Hd. type" field to indicate "payload 
start/payload end".  (This would reduce the range of possible header types 
from 256 to 64.)

I'm assuming here that a fragmented packet must be received in its entirety 
in order for it to be useful.  If that's not the case - i.e., if you want 
partially-received fragments to be useful, then you should instead do 
application-level framing, and make each 'fragment' its own 'header'.

         Ross.

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 17 Jul 2001 14:31:56 +0200

Hi Ross,

My intention is that all profile should make every effort to have each object
fragment (packet) useful in itself. But at the same time they are part of a
larger object. Therefore there must be support to reassembly this larger object.
The problem here compared to audio or video is that the media decoder may not be
involved in the defragmentation, only the payload depacketizer. This may require
extra headers in the payload for defragmentation, so that the fragment can be
located in the correct position. For an example, see the text fragmentation
header, it ensures that a text fragment is placed in the correct layout offset.

Lets look on alternatives to overloading the timestamp field:

1) Add object id number. A header or always required field. Increased for each
new object sent for the source. Suggest 8 or 16 bits which would allow either
256 or 65536 objects on the same timestamp value for a single source. As long as
the timestamp changes before the field wraps there would be no problem.

2) Start and stop markers. The first and last packet in a object is marked.
Would use only two bits. Packet loss of the boundary packets may result in loss
of two complete objects. Requires that all object fragments are sent in
consecutive sequence numbers.

More suggestions?

Cheers

Magnus

--

Magnus Westerlund

---

From: Ross Finlayson <[email-masked]>
Date: Tue, 17 Jul 2001 13:20:03 -0700

>Lets look on alternatives to overloading the timestamp field:
[...]
>Would use only two bits.
[...]
>Requires that all object fragments are sent in

Yes, this is a common way for RTP payload formats to handle fragmentation.

>  Packet loss of the boundary packets may result in loss
>of two complete objects.

The usual way to avoid this is to require that any incomplete fragments 
(beginning, middle, or end) appear by themselves in a RTP packet, and are 
not packed with any other data.

Of course, with the "start/stop marker" approach, if any fragmented packets 
are lost, the whole object is lost.  However, you say that this is 

>larger object. Therefore there must be support to reassembly this larger 

OK, so, if this is the case, then each fragment needs to contain some 
identification of (i) the object that it belongs to, and (ii) the 
'subobject' that it is.  (And of course in the common case where an object 
is not fragmented, you need only one of these.)  None of this has anything 
to do with timestamps, as far as I can tell...

         Ross.