Re: [AVT] Review of draft-versteeg-avt-rapid-synchronization-for-rtp-02> > 2. At the end of section 4 " For example, MPEG decoders require a

[Ye-Kui Wang <yekuiwang at huawei.com>]

Just a clarification on the video buffering discussion.
 
> > 2. At the end of section 4 " For example, MPEG  decoders require a 
> > significant amount of content to be available in the 
> decoder buffers 
> > prior to starting to decode the content."
> > Is this true for all MPEG codecs and all encoding profiles.
> 
> For virtually all related to broadcast systems. The MPEG 
> specification is quite clear about the timing requirements. 
> There are some low-delay codecs that have quite short 
> buffering requirements, but these tend to be 
> video-conferencing style codecs rather than broadcast style codecs.
>  

All video coding standards, including both MPEG ones and ITU-T ones, specify
video buffering models, sometimes named hypothetical reference decoder
(HRD), sometimes named video buffer verifier (VBV). For most, if not all, of
the video codecs, the amount of data to be availalbe in the pre-decoding
buffer or coded picture buffer is decoded by the initial pre-decoding buffer
or coded picture buffer delay as well as the bitrate that data flows into
the buffer. The initial delay and the bitrate values can both be configured
and included in the bitstream by the encoder during encoding according to
the required end-to-end delay for the target application scenario(s). 

Therefore, the sentence in question should still be informativeas, yet more
accurate and not confusing, if it is changed to something as follows:

"For example, standard video decoders typically require an amount, sometimes
a significant amount, of coded video data to be available in the
pre-decoding buffers prior to starting to decode the video bitstream."

BR, YK

> -----Original Message-----
> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On 
> Behalf Of Ali C. Begen (abegen)
> Sent: Friday, March 13, 2009 11:15 AM
> To: Roni Even; IETF AVT WG
> Subject: Re: [AVT] Review of 
> draft-versteeg-avt-rapid-synchronization-for-rtp-02
> 
> > Hi,
> > I read the draft and have some feedback.
> 
> Thanks for the detailed review, Roni.
> 
> > 1. In section 1 " The feedback target starts a unicast 
> retransmission 
> > RTP session and sends the Reference Information to the 
> receiver over 
> > that session.  If there is spare bandwidth, the feedback target may 
> > also burst the Reference Information at a faster than natural rate."
> > 
> > I was under the impression that spare bandwidth is 
> required. Are you 
> > suggesting here that the RR may use the unicast stream for 
> the whole 
> > time if no spare bandwidth is available.
> 
> Not that it is impossible, but would not make much sense. Do 
> you think we need rewording here?
> 
> > 3. In section 5 "Rapid synchronization is an optimization 
> of a system 
> > that must continue to work correctly whether or not the 
> optimization 
> > is effective, or even fails due to lost control messages, 
> congestion, 
> > or other problems.  This is fundamental to the overall design 
> > requirements surrounding the protocol definition and to the 
> resource 
> > management schemes to be employed  together with the 
> protocol (e.g., 
> > QoS machinery, server load management, etc).  In particular, the 
> > system needs operate within a number of constraints."
> > 
> > Do you require resource management scheme as part of the 
> solution, I 
> > think that the solution MUST work also on the free Internet
> 
> Why do you think it must work? It can work, but bad things 
> may happen. 
>  
> > 4. In section 5 " Similarly, using a TCP (or TCP-like) 
> approach with a 
> > 3-way handshake and slow-start  to avoid inducing congestion would 
> > defeat the purpose of attempting rapid synchronization in the first 
> > place by introducing many RTTs of delay."
> > I think that calls for some mechanism to find the optimal rate for 
> > starting the burst. I think this is discussed in the Peilin draft.
> 
> There are ways of detecting a good rate for the burst (not 
> the optimal one). And we can discuss them in the session.
>  
> > 5. In 6.2 editor note. My view is that having the entities 
> physically 
> > co-located in this draft make sense and the text should 
> state it and 
> > suggest that physical decomposition is for futher study.
> 
> Sounds good.
>  
> > 6. In 6.2 step 6 " RS may know when it needs to stop the 
> unicast burst 
> > based on the burst parameters , or RR may explicitly let RS 
> know the 
> > sequence number of the first RTP packet it received from 
> the multicast 
> > session, or RR may request RS to terminate the burst immediately."
> > 
> > I think that if the RS stops the burst by his own decision 
> may cause a 
> > gap.
> 
> Not if carefully engineered.
> 
> > The question is what is better to have a gap and fill it using 
> > retransmit or having both unicast and multicast 
> simultaneously for a 
> > short time. Gap WILL always require action while overlap MAY cause 
> > congestion loss.
> 
> RS can carefully be engineered to allow a minimal overlap. 
> IMO, I think that is better than leaving a gap.
> 
> > 7. In the same step 6 " In the latter case, RR SHALL include the 
> > sequence number of the first RTP packet received in the SSM 
> session in 
> > the RMS-T message, and RS SHOULD terminate the burst after it sends 
> > the RTP burst packet whose OSN field in the RTP 
> retransmission payload 
> > header matches this number minus one."
> > 
> > I am wondering what happens if the RS decided to stop the 
> burst before 
> > receiving RMS-T. The RR may never receive the packet in with the 
> > requested SN and may wait or start request for retransmission.
> 
> If RS terminates proactively without an RMS-T, RR may do 
> retransmission to fill the gap (if any).
> 
> > There is also a typo OSN should be SN
> 
> OSN is the "original seqeunce number" field (RFC 4588).
> 
> > 8. In 6.4 "In the case RR starts receiving an RTP burst but it does 
> > not receive a corresponding RMS-I message  within a 
> reasonable amount 
> > of time, RR MAY either discard the burst data and stop the burst by 
> > sending an RTCP BYE message to RS, or decide not to 
> interrupt the RTP 
> > burst and be prepared to join the primary multicast session at an 
> > appropriate time it determines or indicated in a subsequent RMS-I 
> > message."
> > 
> > I think that since another RMS-I is not mandatory this will 
> be a good 
> > reason to have a rate adaption message from RR to RS as 
> defined in the 
> > Peilin draft.
> 
> Not sure if I follow.
> 
> > 9. In section 7 "Specific payload formats are not defined in this 
> > document, but a framework is presented that allows payload-specific 
> > information to be included in the exchange ."
> > I assume this is future text, look also at RFC 4585 
> application layer 
> > message.
> 
> For mpeg2-ts, we already have a draft:
> http://tools.ietf.org/id/draft-begen-avt-rtp-mpeg2ts-preamble-00.txt
> 
> > 10. Editorial comment on section 7.1 - 7.3, maybe use the 
> format for 
> > specifying messages in RFC 4585 section 6.3
> 
> Sure.
>  
> > 11. In section 7.1 you have the MIN RMS and Max RMS buffer fill 
> > explaining what the RS behavior should be if specified but 
> there is no 
> > text that explains what should the RS do if they are not specified.
> 
> That means RR does not care about the burst's 
> characteristics. RS may send whatever it decides to.
> 
> > 12. In section 7.1 the same comment on max bit rate but 
> here I think 
> > that the RR should always send it to allow for a optimal 
> burst speed.
> 
> We rather wish to keep it optional. 
> 
> > 13. In section 7.1 the length of the feedback message is 
> specified in 
> > octet?
> 
> Yes, this is already fixed for the next revision.
> 
> > Why not use the same semantics of RFC 4585 section 6.1
> 
> That section is pretty similar to ours. Do you want us to 
> include the common fields as well?
>  
> > Length: 16 bits
> >       The length of this packet in 32-bit words minus one, 
> including 
> > the
> >       header and any padding.  This is in line with the 
> definition of
> >       the length field used in RTCP sender and receiver reports [3].
> 
> Oh about the length field. Sure, we can do this. 
>  
> > 14. In section 7.2 " It also includes other useful information for 
> > RR." This is a general sentence, do you need it?
> 
> With future extensions, further useful information can be 
> provided. In the existing message format, join-time, 
> burst-duration, etc are all useful information for RR.
>  
> > 15. in Section 7.2 response parameter. If the value is 1 does it 
> > require that existence of the following optional parameters 
> which are 
> > not needed for value 0 or 2.
> 
> IGMP join time field must be populated in at least of the 
> RMS-I messages. The rest is optional. This should be less 
> cumbersome if/when we transition to TLV for these fields.
> 
> > 16. In section 7.2 response parameter. If the value is 2 I 
> assume that 
> > there is no reason to retransmit a message with this value 
> since the 
> > previous condition for join may not exist. (this is an assumption 
> > since you do not explain the motivation to send this value)
> 
> Makes sense. But, as it is optional, I believe it is up to 
> the implementation.
>  
> > 17. In section 7.2 "Earliest IGMP Join Time (32 bits):  Time 
> > difference between the arrival of the RMS-I message  and 
> the earliest 
> > time instant when RR could join the new multicast session (in RTP 
> > clock ticks)"
> > How does the
> > RS know when "the arrival" will happen?
> 
> If you think that the one-way delay will cancel out, it fits 
> nicely. It says "join the mcast session X clock ticks or ms 
> after you received this message."
> 
> > 18. In section 7.2 what is the use of Rapid Synchronization 
> Duration, 
> > what happens if not specified and is there any relation to 
> IGMP join 
> > time
> 
> If you wanna allow a small overlap, the igmp join time should 
> indicate a time a little bit earlier than the the burst will 
> terminate. So, it is related. But, other implementations may 
> not use it and rather prefer "real-time join" signaling.
>  
> > 19. In Section 7.2 what is the relation between Mac Burst 
> Rate and the 
> > max receive bit rate in RMS-R. Is this value the maximum 
> that the RS 
> > can send or is it the maximum he will use.
> 
> The max bitrate RS will use has to be no larger than the max 
> receive bitrate RR indicates in the RMS-R message. The 
> requested message rate may exceed some threshold (like 
> aggregate access network bandwidth) that is known by the RS 
> but not known by the RR.
>  
> > 20. In section 7.3 there are two options when to send the RMS-T 
> > message. Any recommendation or motivation to use one or the other.
> 
> This is implementation specific. Related to your earlier 
> question whether to allow a small overlap or leave a gap.
> 
> > 21. The example in 8.2 is a bit confusing to me. I see that 
> this is an 
> > SDP from the multicast source. Is this an offer, and answer 
> or is it 
> > an declarative SDP.
> 
> It is a declarative SDP.
> 
> > 22. On the syntax of the example in 8.2 why you have the video as 
> > receive only if this SDP is from the multicast source. Also there 
> > should be one fmt line and the parameters should be separated by 
> > semi-colon.
> 
> Did not know that. Will fix it.
> 
> I hope I have not skipped any question.
> 
> BR,
> -acbegen
>  
> > 
> > Regards
> > Roni Even
> > 
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>