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> 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>
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
>>