[AVTCORE] ***SPAM*** 7.478 (5) Re: Mail regarding draft-ietf-avtcore-clksrc

The timestamp in SRs is NTP format but RFC 3550 does not require you to get
those time stamps from a specific clock. This RFC (7273) allows you to
signal what clock you're using so senders and receivers can synchronize.
Prior to RFC 7273, receivers made undisclosed assumptions about clocks or
simply adjusted empirically to whatever clocking the sender is doing. The
improvement here is to have a common clock for multiple senders so that
streams can be readily combined at a receiver that is receiving multiple
streams from different senders.

Kevin Gross - AVA Networks

On Mon, Dec 15, 2014 at 7:53 AM, Julius Friedman <juliusfriedman@gmail.com>
wrote:
>
> I'll check out that section and re-write in if necessary.
>
> One thing on your response I have to clarify.
> The sr allowed this synchronization.
>
> The reference clock is virtually set to the time difference between the
> ntp timestamp in the sender report and the receiver.
>
> That's seems synchronized to me.
>
> What difference does it make if his clock is wrong? Furthermore if sender
> uses a clock on mars.
>
> Can you succinctly state why we need to know more details about clock rate
> than already available 20 years later?
>
> How does my application benefit from this?
>
> Furthermore it seems dynamic clock rates are not addressed.
>
> Thanks for responding.
> On Dec 15, 2014 3:11 AM, "Brandenburg, R. (Ray) van" <
> ray.vanbrandenburg@tno.nl> wrote:
>
>>  Hi Julius,
>>
>>  Thanks for your constructive and positively-formulated feedback.
>>
>>  I advise you to read section 2 on Applications. It will answer most of
>> your questions.
>>
>>  Furthermore, you seem to have missed a number of aspects:
>>
>>  - There is a difference between a media clock and a reference clock. I
>> don’t see how any RTP profile or current SDP is going to help you to know
>> which reference clock you’re using. Without that information, how are you
>> going to synchronize two different receivers?
>> - There is a difference between specifying a media clock rate (which is
>> done in an RTP profile) and specifying how that clock rate is determined.
>>
>>  If you have any more questions, I encourage you to voice your opinion
>> on the AVT mailing list.
>>
>>  Best regards,
>>
>>  Ray
>>
>>
>>   From: Julius Friedman <juliusfriedman@gmail.com>
>> Date: Sunday 14 December 2014 18:37
>> To: "draft-ietf-avtcore-clksrc@tools.ietf.org" <
>> draft-ietf-avtcore-clksrc@tools.ietf.org>
>> Subject: Mail regarding draft-ietf-avtcore-clksrc
>> Resent-To: "aidan.williams@audinate.com" <aidan.williams@audinate.com>, <
>> hans.stokking@tno.nl>, Kevin Gross <kevin.gross@avanw.com>, Ray van
>> Brandenburg <ray.vanbrandenburg@tno.nl>
>>
>>   What is the purpose of this rfc?
>>
>> After reading it several times I just cannot come to terms with anything
>> it suggests.
>>
>> Rfc 3550 conveys the ntp time information via rtcp et al.
>>
>> There is no reason to signal rate of media in sdp beyond where each rtp
>> profile registered has a default clock rate assigned especially when the
>> document provides no mechanism to align the clocks in which it declared
>> might not be synchronized. (Even though that is the purpose of ntp... )
>>
>> Here is a simple explanation.
>> http://www.cs.columbia.edu/~hgs/rtp/faq.html#sr-timestamp
>>
>> Furthermore each implementation already has the clock rate as a parameter
>> of the rtpmap or fmtp or the profile default is used.
>>
>> This document makes sdp content longer and more complex without any added
>> benefit or explanation of the mechanism introduced.
>>
>> Lastly Video walls wouldn't need a specified rate to work as they would
>> have their own rate and update displays based on that rate.
>>
>> Any such required information would be an optimiZation to their display
>> driver through the operating system, do you really want a rtp sender to be
>> able to control the clock rate of your display? If you do use snmp or
>> something else.
>>
>> Things have worked like this for as long as rtp has been specified and
>> thus this rfc only allows information to be given which is redundant given
>> the fact a profile which would be required for playback through
>> depacketization anyway.
>>
>> This document also makes no change to any calculation used by a receiver
>> or sender.
>>
>> It is for all intents and purposes useless.
>>
>> Please feel free to correct me.
>>
>> Sincerely,
>> Julius Friedman.
>>
>>
>>
>> This message may contain information that is not intended for you. If you
>> are not the addressee or if this message was sent to you by mistake, you
>> are requested to inform the sender and delete the message. TNO accepts no
>> liability for the content of this e-mail, for the manner in which you use
>> it and for damage of any kind resulting from the risks inherent to the
>> electronic transmission of messages.
>>
>>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>
>