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

Hi Julius,

I think we’re talking about two different use cases. The use you seem to have in mind is one where the issue at hand is synchronization of two or more streams on a single device. For that purpose, you’re right that it doesn’t matter which clock you’re using (as you mention, it might as well be a Mars-based one).

The use case that is discussed in the RFC is where you have multiple receivers and where the goal is to make sure that the streams being played out are synchronized between the various receivers. Imagine a stadium where you have multiple RTP-connected speakers. In that case, it is very important that the reference clock they are using is the same, or at least that you know the offset between those clocks.

> This literally makes no sense because even if I knew what clock the sender was using I might not be able to access it.
Well, this draft solves the former problem, knowing which clock the sender was using. Not having access to that particular server is another problem altogether. As long as that is not the case in the overwhelming majority of the cases, I don’t think that is reason to disqualify this work.

Ray

From: avt [mailto:avt-bounces@ietf.org] On Behalf Of Julius Friedman
Sent: maandag 15 december 2014 17:37
To: Kevin Gross; avt@ietf.org
Subject: Re: [AVTCORE] Mail regarding draft-ietf-avtcore-clksrc

This literally makes no sense because even if I knew what clock the sender was using I might not be able to access it.

What if there is confusing information about a source?  E.g. its true identity.

How is this any better then just adjusting to the sender's time any why..

After all the sender could just as well switch clocks again.

Multiple streams are combined by a mixer and hence the mixer accounts for the rate adjusting if required to mix each sample.

This doesn't really help a mixer perform that function any easier for the reasons stated and only would under situations where it was designed to.

Receivers using legacy algorithms or profiles would still be able to do this if required by their system when required based on better information than conveyed as indicated in this draft.

On Dec 15, 2014 11:25 AM, "Kevin Gross" <kevin.gross@avanw.com<mailto:kevin.gross@avanw.com>> wrote:
>
> 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<mailto: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<mailto: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<mailto:juliusfriedman@gmail.com>>
>>> Date: Sunday 14 December 2014 18:37
>>> To: "draft-ietf-avtcore-clksrc@tools.ietf.org<mailto:draft-ietf-avtcore-clksrc@tools.ietf.org>" <draft-ietf-avtcore-clksrc@tools.ietf.org<mailto:draft-ietf-avtcore-clksrc@tools.ietf.org>>
>>> Subject: Mail regarding draft-ietf-avtcore-clksrc
>>> Resent-To: "aidan.williams@audinate.com<mailto:aidan.williams@audinate.com>" <aidan.williams@audinate.com<mailto:aidan.williams@audinate.com>>, <hans.stokking@tno.nl<mailto:hans.stokking@tno.nl>>, Kevin Gross <kevin.gross@avanw.com<mailto:kevin.gross@avanw.com>>, Ray van Brandenburg <ray.vanbrandenburg@tno.nl<mailto: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<mailto:avt@ietf.org>
>> https://www.ietf.org/mailman/listinfo/avt
>>