[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MMUSIC] I-D Action:draft-ietf-mmusic-rfc2326bis-21.txt
Hi,
Thanks for your comments. See inline for each individual item. The
changes made will be able in the 22 version.
Jaehwan Kim skrev:
> Hi,
>
> It seems that the biggest change is 'DVD Player remote control' because
> I always introduced people RTSP as a TV remote control protocol.
>
> And I would like to share some my comments, originally written for my
> better understanding, if you don't mind.
>
>> (Page18) When the server is notifying the client about the end of the
> media delivery requested using PLAY, it sends a PLAY_NOTIFY request to
> the client.
> [jh]The right intention looks "When the server wants to notify the
> client about the end of the media delivery, it can send a
> PLAY_NOTIFY..."
Yes, I changed this to:
When the server want to notify the client about the completion of the
media delivery, it sends a PLAY_NOTIFY request to the client.
>
>> (Page18) The PLAY_NOTIFY request includes information about the last
> RTP sequence numbers for each stream, and thus enables correct handling
> of the buffer drainage at the end.
> [jh] How about this? "The PLAY_NOTIFY request includes the last RTP
> sequence number for each stream to help the player to empty the buffer
> smoothly."
Yes, reworded it somewhat:
The PLAY_NOTIFY request includes information about the stream end,
including the last RTP sequence number for each stream, thus enabling
the client to empty the buffer smoothly.
>
>> (Page19) For video is possible to manipulate the number of frames that
> is displayed per second, but...
> [jh] This part could be enhanced like below. Correct me if I am wrong.
> Some 'this' are ambiguous to me.
>
> "For video, it is possible to manipulate the framerate on the fly,
> although the randering capabilities are often limited to certain frame
> rates. And the allowed contents bitrate also limits the modification of
> the framerate. Therefore, basically fast forward feature could be
> implemented in this regards in which some subset of the frames from the
> original content could be picked up. However, the result of this way
> would be different from the video encoding methods.
>
> Due to the media characteristics, possible scale ratios is commonly
> limited. To signal right scale ratio information, RTSP has a way of
> indicating the supported Scale ratios for the content. To support
> aggregated or dynamic content, where the scale may change during the
> session and this change is dependent on the location within the content,
> a mechanism for updating the media properties and the currently used
> scale factor exists."
>
I want to keep this reasonably non-specific when it comes to the codec.
Is this better?
For video is possible to manipulate the frame rate, although the
rendering capabilities are often limited to certain frame rates. Also
the allowed bit-rates in decoding, the structured used in the encoding
and its dependency between frames and other capabilities of the
rendering device limits the possible manipulations.
Due to the media restrictions, the possible scale values are commonly
restricted to a limited set of possible scale ratios. To enable the
clients to select from the possible scale values, RTSP can signal the
supported Scale ratios for the content. To support aggregated or dynamic
content, where this may change during the ongoing session and dependent
on the location within the content, a mechanism for updating the media
properties and the current used scale factor exist.
>> (Page20) Speed affects how much of
> [jh] I think this parts overally should be re-reviewed. Or I would
> revisit here again later.
>
Well, it is a lot of new text. When it comes to this I do need feedback
what is problematic with the text. Writing about speed and scale is
problematic.
>> (Page25)
> transport. A message is either a Request or a Response.
>
> Message Body: The information transferred as the payload of a
> message. A message body consists of meta-information in the
> (snip)
> [jh] the expression, "either a request or a response" should be in the
> message body. It helps RTSP implementers to consider message body even
> in the request which is not common in basic operation. Therefore, rather
> the original sentence in draft20 looks better. And I think "The
> information transferred as the payload of a request or response." could
> be rephrased to "The contents of the message without the message header
> in either RTSP request or response message."
I have clarified that this is either a request or a response. But your
suggested phrasing is a the invert that isn't fully true as there can be
other parts in a message. I try to write what it is.
>
>> (Page141) The server SHALL
> respond if the session is in playing state with the Range header
> filled in with the current playback point and with the corresponding
> RTP-Info values.
> [jh] Original one looks more clear. It would be enhanced like below,
> though.
> "The server SHALL respond if the session is in playing state. Then, that
> response MUST have RTP-Info value which is corresponding to the given
> Range value."
Okay, is this clearer?
The RTP-Info header and the Range header MAY be included in a
GET_PARAMETER request from client to server without any values to
request the current playback point and corresponding.RTP synchronization
information. When the RTP-Info header is included in a Request also the
Range header MUST be included (Note, Range header only MAY be used). The
server respons SHALL include both the Range header and the RTP-Info
header. If the session is in playing state, then the value of the Range
header SHALL be filled in with the current playback point and with the
corresponding RTP-Info values. If the server is another state, no values
are included in the RTP-Info header.
>
>> (Page250)
> S->C: PLAY_NOTIFY rtsp://example.com/fizzle RTSP/2.0
> CSeq: 45
> Notify-Reason: end-of-stream
> Request-Status: cseq=4 status=200 reason="OK"
> Range: npt=-15
> RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
> ssrc=0D12F123:seq=49;rtptime=39200
> Session: abcdefgh
>
> C->S: RTSP/2.0 200 OK
> CSeq: 854
> User-Agent: PhonyClient/1.2
> [jh] CSeq looks mismatched.
>
Fixed.
Thanks for the comments
Magnus Westerlund
IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB | Phone +46 10 7148287
Färögatan 6 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund at ericsson.com
----------------------------------------------------------------------