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

[Ivica Rimac <[e-mail]>]

Hi,

we are also thinking of an application combining live streaming of 
continuous media with time-lined static media objects. The idea is to 
transfer slides of a lecture (binary static object) synchronized with 
the spoken explaination (audio).

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.

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

Has there been any follow-up discussion?

> Hi Magnus,
> 
> It was good to learn of your views on Flute! We have been thinking on similar lines about the possible use SMIL for synchronizing Flute transfers with media streams. The use of SDP for describing the sessions of the FLUTE protocol has been in the plans. We have also been preliminarily considering the use of both SMIL and SDP for our work on Internet Media Guides in MMUSIC.
> 
> Looking forward to seeing you in Minneapolis!
> 
> -Pekka
> 
> -------------------
> Juha-Pekka Luoma
> Nokia Research Center
> Tampere, Finland
> -------------------
> 
> > -----Original Message-----
> > From: ext Magnus Westerlund [mailto:[e-mail]]
> > Sent: Thursday, October 30, 2003 11:42 AM
> > To: Takeshi Yoshimura
> > Cc: Walsh Rod (NRC/Tampere); [e-mail]; [e-mail]
> > Subject: Re: [MMUSIC] time-lined static media with FLUTE & IMG
> > 
> > 
> > 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
> > > 
> > > 
> > >>Hi Magnus, Ross (and everyone)
> > >>
> > >>1$B%9(J-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.
> > 
> > -- 
> > 
> > Magnus Westerlund
> > 
> > Multimedia Technologies, Ericsson Research EAB/TVA/A
> > ----------------------------------------------------------------------
> > Ericsson AB                | Phone [phone]
> > Torshamsgatan 23           | Fax   [phone]
> > S-164 80 Stockholm, Sweden | mailto: [e-mail]
> > 
> > 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> -mail]
> https://www1.ietf.org/mailman/listinfo/avt


-- 

Best regards,

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


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