Subject: Re: [MMUSIC] RE: [dccp] natural DCCP sender-side API: (was stream switching)

From: [email-masked]
Date: Thu, 24 Jul 2003 16:58:12 +0200

Hi Damon,

>> >So, in this scheme, the sender doesn't need to know the rate that TFRC has
>> >determined, it simply always sends as fast as TFRC allows.
>>
>> 1) I am sorry but *from a network point of view*
>> I dont see a difference between this and "download"?
>
>The only substantive difference is that the transmitted data may not be
>stored statically on the device in the case of streaming.  So if you
>have a small embedded device, with limited storage, you can experience
>media from the network without having the cache the whole thing on the
>device.

with progressive download  if you have no room for storage
you can garbage media  as soon as it is decoded as well ...
and slow down the sender if needed too ...

regards,

Philippe Gentric
Software Architect
Philips MP4Net
[email-masked]
http://www.platform4.philips.com

                                                                                                                                       
                                                   To:   Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1                                     
                                                   cc:   "Phelan, Tom" <[email-masked]>                                          
                                                    [email-masked]                                                                      
                                                    [email-masked]                                                                    
               Damon Lanphear                      Subject:    [MMUSIC] RE: [dccp] natural DCCP sender-side API: (was stream           
               <[email-masked]>                  switching)                                                                         
                                                                                                                                       
               Sent by:                            Classification:                                                                     
               [email-masked]                                                                                                   
                                                                                                                                       
               23/07/2003 21:42                                                                                                        

On Wed, 2003-07-23 at 10:43, [email-masked] wrote:
> Hi Tom,
>
> you write:
>
> >The relevant difference, as far as this discussion goes, between recorded
> >and live media is that recorded media can be transmitted from the sender as
> >fast as the network allows (assuming buffering at the receiver).
>
> and then latter (still about recorded media):
>
> >So, in this scheme, the sender doesn't need to know the rate that TFRC has
> >determined, it simply always sends as fast as TFRC allows.
>
> 1) I am sorry but *from a network point of view*
> I dont see a difference between this and "download"?

The only substantive difference is that the transmitted data may not be
stored statically on the device in the case of streaming.  So if you
have a small embedded device, with limited storage, you can experience
media from the network without having the cache the whole thing on the
device. The problem then becomes one of balancing the use of device
storage (i.e. client buffer management) and congestion control.

>
> Except that to my knowledge all the products doing that use HTTP
> since it solves a rather large number of other problems at the same time!
>
> 2) Now *from a user point of view*
>
> "download" has a flavor usually called "progressive download"
> whereby the downloaded media file has a structure enabling
> to start playback before download is finished.
>
> In this mode usually the slide bar that the player
> uses to display the media time has 2 colors,
> one displaying the current time in the media,
> the other the *received* time in the media,
> if this second mark stays ahead of the first mark playback is un-interrupted,
> otherwise the player stops and displays a message such as "please wait, rebufferring".
>
> So I dont see either, from a user point of view,
> how different a behavior the case you describe would have?
>
> ****************
>
> I conclude about this use case of the DCCP blocking API you described,
> that it is not very attractive at all.
>
> Surely DCCP has better assets to lure implementers?-)...
> I think an API providing a target rate would be a good starting point;-)
>
> regards,
>
> Philippe Gentric
> Software Architect
> Philips MP4Net
> [email-masked]
> http://www.platform4.philips.com
>
>
>
> _______________________________________________
> dccp IETF mailing list: [email-masked]
> list info:  https://www1.ietf.org/mailman/listinfo/dccp
> wg charter: http://www.ietf.org/html.charters/dccp-charter.html
--
Damon Lanphear <[email-masked]>

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Damon Lanphear <[email-masked]>
Date: 24 Jul 2003 12:12:02 -0700

> and slow down the sender if needed too ...

At this point, then why bother creating a differentiation between
progressive download and streaming?  If you are tossing data you just
received from the network and decoded, you haven't actually downloaded
anything in the traditional sense of the word.