Subject: RE: [AVT] RE: [MMUSIC] time-lined static media with FLUTE & IMG

From: [email-masked]
Date: Wed, 17 Dec 2003 11:59:34 +0200

Hi Ivica

Great to hear you're interested in this field.

> Has there been any follow-up discussion?

Not much so far. I think the related people are hammering away at other problems at the moment, so this one is queued (at least for me).

> Now since Magnus does not think there is a straightforward 
> solution, I 
> am wondering where I might be wrong?

I think Magnus was refering to FEC (for RTP). The references where not ALC FEC references. I (also) am not a FEC expert, but if you have an idea of what your application reliability and network loss characteristics might be, it should be easier to assess what kind of FEC scheme would suit. Fortunately ALC's designed to allow new and old schemes to 'plug-in' staightforwardly. You just need the FEC spec that meets your needs.

As I interpretted it, Magnus highlighted 3 issues needing solution:
1. How to achieve synchronisation
2. How to reference downloaded binary objects
3. Session description (declaration) of FLUTE sessions (e.g. SDP extension)

You have addressed (1) with "providing additional timing attributes to the FDT"...

> Looking into the FLUTE draft, it seems to already provide the 
> necessary 
> means for reliable transfer of time-lined static media: providing 
> additional timing attributes to the FDT. With the latter and the RTP 
> timing information, the application can synchronize both 
> media objects.

Which makes sense. Essentially I can see three simple solutions for (1):
1. describe the timing information in the FDT as an extension (your suggestion)
2. describe the timing information in the FDT in a seperate object (e.g. in a SMIL file - Magnus's suggestion)
3. use the expires field already in the FDT as the implicit timing field (I not convinced whether this is a good idea)

If you've got a spec of any of these I'd be happy to distrubte and review it.

Irrespecive of how you solve (1), you need to solve (2) - how to reference "downloaded binary objects" (aka "files"). FLUTE already gives you URIs to identify files so the simple way is to use these. If you want to be globaly unique, I guess you'll choose URLs (rather than URNs) although there's the consideration of whether HTTP://... is going to be resolved to an HTTP GET by your application if it's not savvy with what's being multicast. Could just use relative URLs, or even define a new FLUTE URL. For me everything is fine as is (it's easy to reference a URI and take care that you understand it's uniqueness in whatever domain). If anyone sees some significant problems with this, please highlight them - especially whether we need a FLUTE URL (since that needs an Internet-draft).

Finally, to solve (3) you need to define a FLUTE Session Description Syntax/extension. It's a fair bet that SDP will be with us for some time ahead so an SDP extension seems to be the minimal Internet-draft for general Interent usage. This is on my todo list, unless someone else does it first.

BTW, one of the open source FLUTE implementations is available here:
http://atm.tut.fi/mad/

Cheers, Rod

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

---

From: Ivica Rimac <[email-masked]>
Date: Wed, 17 Dec 2003 11:26:48 +0100

Hi Rod,

thank you for your answer. See my comments inline:

> If you've got a spec of any of these I'd be happy to distrubte and review it.

Thought of SMIL-like attributes:

<xs:attribute 	name="Content-Begin"							 
type="xs:unsignedLong"								use="optional"/>
<xs:attribute 	name="Content-Duration"						 
type="xs:unsignedLong"								use="optional"/>

If "Content-Duration" is not provided, the object is displayed until the 
end of the session or until the beginning of a new FLUTE object with the 
same TOI.

> Irrespecive of how you solve (1), you need to solve (2) - how to reference "downloaded binary objects" (aka "files"). FLUTE already gives you URIs to identify files so the simple way is to use thes…

The idea was to use relative URLs, conforming to your thoughts, since 
all the objects are locally cached in the end-device. Thus, there is no 
need for changes. The rest is up to the application.

> Finally, to solve (3) you need to define a FLUTE Session Description Syntax/extension. It's a fair bet that SDP will be with us for some time ahead so an SDP extension seems to be the minimal Inter…

Agree, this seems to be an open issue.

-- 

Best regards,

+--- Ivica Rimac -----------------------------------------------+
|               KOM - Multimedia Communications                 |
| Department of Electrical Engineering & Information Technology |
|              Darmstadt University of Technology               |
|                    email: [email-masked]     |
|     Merckstr. 25   tel.:  +49-6151-16-6112  (Fax -6152)       |
|  64283 Darmstadt   http://www.kom.e-technik.tu-darmstadt.de   |
+---------------------------------------------------------------+