Re: [AVTCORE] Mail regarding draft-ietf-avtcore-clksrc

[Julius Friedman <[e-mail]>]

Ntp synchronized receivers.

This mechanism is additional and allows for more error for the reasons I
already stated.

You can synchronize with rtcp alone.

Additionally if my speakers are not ip compatible then your notion and
reference makes little sense.

There is no reason for a new sdp line and new semantics for clocks without
properly defining the scenarios i have outlined and their resulting effects
on existing systems.

Hence my position is unchanged.
On Dec 17, 2014 8:51 AM, "Brandenburg, R. (Ray) van" <
[e-mail]> wrote:

>  Hi Julius,
>
>  >Disagree all you like, until you can articulate a succinctly defined
> scenario which also handles the issues I cite then I will file errata for
> them and will not comply with them until such time.
>
>  The decision whether to comply or implement this RFC is completely up to
> you. Nobody is forcing you to implement something you don’t think is
> necessary. Implementing any RFC is optional, including this one. If you
> don’t agree with the use case or solution provided, no problem, don’t
> implement it
>
>  >The latter scenario is made up
>
>  No, it’s not. As an example: http://en.wikipedia.org/wiki/AES67. This is
> an A/V Networking  specification that is implemented and used by a number
> of companies, as announced in various public press releases. The clock
> source RFC that we’re discussing here is a normative reference in that
> specification. Another example is RFC7272, which present a solution for
> synchronising playback on different receivers.
>
>  Ray
>
>
>
>   From: Julius Friedman <[e-mail]>
> Date: Wednesday 17 December 2014 14:29
> To: Ray van Brandenburg <[e-mail]>
> Subject: RE: [AVTCORE] Mail regarding draft-ietf-avtcore-clksrc
>
>   Ray / AVT
>
> On Dec 17, 2014 4:10 AM, "Brandenburg, R. (Ray) van" <
> [e-mail]> wrote:
> >
> > Hi Julius,
> >
> > Unfortunately I disagree.
> >
> > Rtp connected speakers dont have to be synchronized to each other. If
> they did each speaker would adhere to the spec as it's own reciever and
> handle loss as indicated in the standard.  They could also have their own
> mechanism for synchronicity as provided by the transport layer.
> >
> > This is not about loss. This is not about the transport layer. This is
> about making sure that if I have a room in which I have multiple
> RTP-connected speakers, they all play out the audio or video at exactly the
> same time. How would the transport layer help with that?
>
> Ntp helps with this.  Each speaker would recieve data from a mixer and
> would play out.
>
> How will knowing the clock rate of the media prevent a unit from
> malfunction?
>
> What if someone spilled something?  Or there was interference?
>
> What is knowing the clock rate going to do for you then?
>
> Lastly how come that scenario isnt made use of in the draft and instead we
> have examples with video walls and iptv systems which have their own
> mechanism for clocks.
>
> >
> > The scenario is no different than a conference where all the
> participants are spread out over vast distances or routes with congestion.
> >
> > No, it’s not. There is a difference between a scenario where the primary
> goal is low-delay (conference systems) and a scenario where the primary
> goal is high quality and synchronicity, in which adding a few seconds of
> delay to make sure everything is synchronized is acceptable. You seem to be
> focused on the former, without considering the latter scenario.
> >
>
> The latter scenario is made up, and if I didn't consider it I wouldn't
> feel so strongly about it.
>
> Just because your proprietary system benefits from this doesn't mean mine
> will nor that I will want to take measures to comply with something which
> raises several concerns which are not addressed.
>
> > There is no reason to obtain or know the clock rate other than how it
> had already been specified because the senders report provides this
> functionality for multiple streams and single streams.
> >
> > No, it doesn’t. The SR doesn’t specify a reference clock, not its
> source. All it does  is specify at what time a specific sample was sent.
> >
>
> The ntp tells you a reference clock of the sender and also tells you that
> the rtptimestamp belongs to that time.
>
> How are you calculating jitter and transit?
>
> Wont those still be applied?
>
> > Doing so in the manner specified by this draft is not backwards
> compatible and provides nothing to prevent the clock rate from changing
> right after it has been conveyed.
> >
>
> The clock source which may not be accessible,  correct or ever change
> reference or rate?
>
> > That is ­_exactly_ the reason why we don’t convey the clock rate but
> communicate the clock source. And I don’t see how making use of this RFC
> has any impact on backwards compatibility.
> >
>
> Its easy,  if I didn't need to look for or account for the source now and
> now I need to this is not compatible.
>
> Also since you don't specifically define how changes are handled in the
> clock among other issues i brought up.
>
>  > There is no benefit, we didn't need this mechanism 20 years ago and we
> certainly dont now.
> >
> > Thanks for sharing your opinion. I disagree.
> >
>
> The facts are still the facts.
>
> I have worked with several types of video walls and iptv systems.
>
> In no aspect did a source clock ever come up or present itself as an
> issue.
>
> I would have loved to hear how this solves an issue in real life rather
> then made up scenarios.
>
> I could also argue that each speaker could have it's own dynamic content
> and due to handicap or special content not require the same play out as
> other speakers.
>
> Disagree all you like, until you can articulate a succinctly defined
> scenario which also handles the issues I cite then I will file errata for
> them and will not comply with them until such time.
>
> Sincerely,
> Julius Richard Friedman
>
> > Ray
> >
> > Because of those reasons as well as the others i have cited my position
> is firm until a succinctly defined scenario is defined in which prior
> mechanisms fail or it is shown a clear and hassle free benefit of complying
> with this draft.
> >
> > After all if I ignored it I would play data the exact same way as if it
> was in use.
> >
> > The sr would adapt receiver losses as it always has.
> >
> > This might be better as some informational document and even then I
> question its applicability in face of existing mechanisms which are better
> defined and more reliable.
> >
> > Sincerely,
> > Julius Richard Friedman
> >
> > On Dec 16, 2014 11:02 AM, "Brandenburg, R. (Ray) van" <
> [e-mail]> wrote:
> >
> > 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:[e-mail]] On Behalf Of Julius Friedman
> > Sent: maandag 15 december 2014 17:37
> > To: Kevin Gross; [e-mail]
> > 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" <[e-mail]> 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 <
> [e-mail]> 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" <
> [e-mail]> 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
>
>
>
> 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.
>
>