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

From: [email-masked]
Date: Mon, 27 Oct 2003 12:51:53 +0200

Hi Magnus, Ross (and everyone)

1½-2 years back there was a draft on time-lined static media (draft-westerlund-avt-rtp-static-media-01) - basically to send files, text (etc) with timed presentation along with AV media streams. Since the basic requirements haven't gone away, but RMT has made progress on usable protocols, what do you think about using FLUTE (draft-ietf-rmt-flute-02) for the same job? With a quick comparison I think it should be pretty straight forward, although you may have some preferences (or extensions to the FLUTE-FDT) if you already have a working RTP-payload'ed implementation.

Ross mentioned sending ID-3 tags in-band with audio streams. Any ideas you have on doing this with FLUTE (ID3) and RTP (music) could be pretty useful for the Internet Media Guide (IMG) work in MMUSIC - how to move around (and announce) metadata for 'foo' multicast and unicast sessions.

Cheers, Rod.

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

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 30 Oct 2003 10:41:34 +0100

Hi,

The static media draft is dead. I have no plans of updating it as I
currently don't think it is the right approach to the problem. The usage
of RTP actually seems rather unnecessary. Most of the functionality in
RTP is not at all needed and other things where missing. Here I find the
FLUTE solution more addressing the problems around binary object
transport for multicast. However I don't know its performance for
unicast, however for any unicast session HTTP is probably usable if one
can schedule the GET command appropriately and to know when to stop
requesting because it is to late.

The FLUTE solution are still missing many vital parts to my
understanding. The first is how to achieve the synchronization. One
could for example use SMIL however this requires one to have resolved
how one performs the referencing to downloaded binary objects. To my
understanding a defined cache utilizing FLUTEs source URI declaration
could be a possibility. There also seem to be shortcoming that no real
effort has been made into defining how the session declaration should be
made.

The usage of RFC 2733 or ULP does not seem to provide the necessary FEC
performance to be used in multicast delivery, at least not for objects
larger than a few packets. However this is not my expertise area, but I
assume there are good reasons why more advanced algorithms like
reed-solomon or tornado codes seem to be used in the area.

I don't think this problem space has any straightforward solutions. It
is hard problems, requiring well thought through solutions. There is
definitely need to do more work in the area.

My personal feeling in regards to MBMS is that the work is to hurried to
be able to produce a good solution.

As a conclusion to the original question, I would say that the
application of FLUTE for time-lined static media delivery as combination
to multicasted continuos media like audio and video requires further
investigation.

Cheers

Magnus

Takeshi Yoshimura wrote:

> Hi Rod and Magnus,
> 
> I'm also considering a reliable and time-lined static media delivery,
> because it is discussed in 3GPP as one of the services over 3G MBMS
> (Multimedia Broadcast/Multicast Service).
> 
> You seem to extend FLUTE for this purpose, but I think combining generic
> RTP format (Magnus's draft) and RTP-FEC format (e.g, RFC2733,
> draft-ietf-avt-ulp, draft-ietf-avt-uxp) is more straightforward way.
> What do you think of this approach?
> 
> Regarding this issue, what's the current status of
> draft-westerlund-avt-rtp-static-media-01?  Is there any technical
> problem with this?
> 
> Best regards,
> Takeshi
> 
> 
>>1ス-2 years back there was a draft on time-lined static media (draft-westerlund-avt-rtp-static-media-01) - basically to send files, text (etc) with timed presentation along with AV media streams. Since the basic requirements haven't gone away, but RMT has made progress on usable protocols, what do you think about using FLUTE (draft-ietf-rmt-flute-02) for the same job? With a quick comparison I think it should be pretty straight forward, although you may have some preferences (or extensions to the FLUTE-FDT) if you already have a working RTP-payload'ed implementation.
>>

-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Takeshi Yoshimura <[email-masked]>
Date: Thu, 30 Oct 2003 18:12:17 +0900

Hi Rod and Magnus,

Best regards,
Takeshi

---

From: Colin Perkins <[email-masked]>
Date: Thu, 30 Oct 2003 10:16:20 +0000

On Thursday, Oct 30, 2003, at 09:12 Europe/London, Takeshi Yoshimura 
> draft-westerlund-avt-rtp-static-media-01?  Is there any technical

There was some discussion of this idea in the past - see the minutes of 
AVT at the 51st (London) IETF for example.

-- 
Colin Perkins
http://csperkins.org/