Subject: RE:[MMUSIC] Presenting draft-westerlund-mmusic-sdp-bwparam-00.txt

From: "Amir Wolf" <[email-masked]>
Date: Wed, 9 Oct 2002 15:15:43 +0200

Hi Magnus,
I agree that a packet rate header may be more sufficient.
Sending the blocksize header in the DESCRIBE request might be a good solution since the server will be able to set the a=prate according to the blocksize.
However, one case is still uncovered  - if the client would like to get different blocksizes for audio and video - it can not be signaled in the DESCRIBE request.
therefore I think that if a server supports the blocksize header - it should response about it in the setup request.

Regarding your question about the Average Bitrate - I think that the main use of the bitrate information is to set the client Buffers in a way that it will not overflow,
However in some cases this can be insufficient especially when you have a constant bitrate and just one peak for a second, Therefore I think that we can add an optional header specifying the Average bitrate.

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]]
Sent: Wednesday, October 09, 2002 12:46 PM
To: Amir Wolf
Cc: [email-masked]; [email-masked]
Subject: Re: [MMUSIC] Presenting draft-westerlund-mmusic-sdp-bwparam-00.txt

Hi Amir,

In the case of RTSP controlled streaming my proposal for handling the 
prate is the following.
- In cases when the server either ignores blocksize or the given 
blocksize allows for the predefined sizes the prate in the SDP from the 
DESCRIBE answer will be used.
-  A client should preferable send blocksize in their DESCRIBE request 
so that a server can modify the value before responding with the SDP.
- In cases when a blocksize is sent with a SETUP request the 
corresponding packet rate needs to be communicated to the client.

I don't think a mandatory maximum blocksize header is useful. The actual 
size of packets sent will be variable and given an upper limit does not 
enable one to calculate the maximum packet rate, rather a minimal packet 
rate. Many codecs actually has easier to calculate a maximum packet rate 
than giving a number on the bit rate. Audio codecs know the maximum 
number of frames they produce each second, and they can give good 
estimates of how many packets each frame will result in. Also 
packetization options like number of frames can easily be taken into 
account. For video codecs the frame rate gives a good starting point and 
the quality and sequence will determine how many packets will be needed 
for each frame. So if we are going to add a RTSP header, a packet rate 
header seems much more useful.

One question I have been asking is it sufficient with a single packet 
rate attribute? The current definition of prate specifies it as a 
maximum. This allows one to calculate the actual maximum bit rate. This 
is seems correct with the TIAS modifier that also is an maximum. But are 
there any need for an average bandwidth specifier?

Best Regards

Magnus

Amir Wolf wrote:

>Emre and All,
>
>I also agree that the Bandwidth information should include only payload.
>regarding the a=prate - I think that the fact that the blocksize header in the SetUp request is not fully implemented in some clients  (since it is not mandatory) and the fact that some servers ignores this header it cause a problem to put correct information in the a=prate.
>A server that ignores blocksize header can know this value in the Init state, but a server that handle this header will not be able to.
>I think that we should add an additional mandatory header for the setup response which will indicate the max blocksize generated by the server, this value can be based on a blocksize header received in the request or not if the server ignores it.
>Having this information and the <b=TIAS> the client will be able to calculate the bandwidth for each media level.
>

-- 

Magnus Westerlund 

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

**************************************************************************************************
The contents of this email and any attachments are confidential.
It is intended for the named recipient(s) only.
If you have received this email in error please notify the system manager or  the 
sender immediately and do not disclose the contents to any one or make copies.

** eSafe scanned this email for viruses, vandals and malicious content **
**************************************************************************************************

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

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 09 Oct 2002 15:51:32 +0200

Hi Amir,

Comments below:

>therefore I think that if a server supports the blocksize header - it should response about it in the setup request.

RFC 2326 is rather unclear on when the blocksize header can be used. In 
the draft to update RTSP blocksize is currently allowed in DESCRIBE, 
SETUP and PLAY. I agree in cases that you want to have different 
blocksizes to different media, you must use it in SETUP. Unless we 
specify a packet rate response header for RTSP the servers way of 
telling of a change in prate is to use ANNOUNCE. The right way forward 
here is probably to define a new header, but more comments are welcome 
on the issue.

>However in some cases this can be insufficient especially when you have a constant bitrate and just one peak for a second, Therefore I think that we can add an optional header specifying the Average…

Thanks for your opinion. Another usage of the bitrate parameters is for 
reservation of resources. In that case the maximum makes sense. The 
maximum value can also be interpreted as with this bandwidth everything 
will work fine. More input please.

Regards

Magnus Westerlund