Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid-rtp-sync-03.txt

[Michael A Dolan <md.1 at newtbt.com>]

Hi Thomas-

Thanks.  Yes, I am familiar with the discussion.

I'm not necessarily pushing the ATSC solution, but offering some points
to consider, which apply equally to the problem at hand here, I
think.

Also, it is important to note some more things about the ATSC
text:

1. The language in the specification very carefully recommends the clock
precision without requiring it.  It is expected to work over routers
with jitter and delays and with media components from outside the
broadcast facility. The difference is that the client is expected to be
able to perform tight sync when the servers are able to provide the
recommended timing model (encoding one hop away, etc).  It
gracefully degrades to "Internet" timing model
quality.

2. The clock, although "NTP" syntax, is not time of day (e.g.
reference_ID="GPS"),
but "PPS", thus allowing the components to be encoded and
decoded without concern for end-to-end delivery delay.  This only
works when NTP is explicitly signaled as part of the encoding and both
components share a clock (same or closely coupled encoders). So it will
not work in the general case.  But there are many systems where it
will and perhaps consideration should be given to permitting
non-"wall clock" timebases.

The NTP hdr ext here is an encoding optimization that indeed has some
other good properties.  Although the draft ties the NTP timestamp
back to the RTCP SR records, the timebase is not explicitly defined
(which is also true of RTCP SR).  Some
reference_ID value must be assumed and
there is enough delta between, for example, GPS and UTC, timebases to
cause things to break if the entire system is not implicitly assumed to
be only one timebase. For example, without an explicit reference_ID, how
could one use other timebases defined in NTPv4?  This is a broader
issue than the hdr ext syntax, but since we're discussing NTP, I thought
I'd bring it up.

I think the above and the other points below are relevant here and
not inconsistent with the RTCP SR methods. The fact that the ATSC design
*can* be more precise is not alone cause to discard the techniques
developed there.

Regards,

        

Mike

At 09:34 AM 3/31/2009 +0200, Thomas.Schierl at hhi.fraunhofer.de wrote:
> Dear Michael,
>
> Thanks for the comments and the reference to the ATSC M/H.
>
> I guess, what we are looking for in AVT is a solution which also works
> for encoders having non-perfect clocks. There was a long discussion on
> the list, here are two pointers:
>
> http://www.ietf.org/mail-archive/web/avt/current/msg09144.html
> http://www.ietf.org/mail-archive/web/avt/current/msg10491.html
>
> ATSC surely can assume to have a perfect clock in the NTP streams, which
> will not be the case on PC systems that may be used as an encoder for
> multi session transmission of a layered codec. This is one major problem
> we intended to solve with the header extension while keeping the whole
> approach as close as possible in line with the existing RTCP SR
> method.
>
>
> Best regards,
> Thomas
>
>
>
> ______________________________________________
> Thomas Schierl, Dipl.-Ing.
> Fraunhofer HHI
> Senior Research Engineer
> Image Processing Dept. / Multimedia Transport
> Einsteinufer 37, 10587 Berlin, Germany
> PHONE: +49 30 31002 227 , FAX: +49 30 392 7200
> WEB: http://ip.hhi.de ,
> SKYPE: thomas.schierl
> EMAIL: thomas.schierl at hhi.fraunhofer.de
>
>
>
> Michael A Dolan wrote:
> > Those interested in this topic
> > may also find this interesting:
> >
> > http://www.atsc.org/standards/cs_documents/a153-2009-03-13/S4-132r13-A153-Part-3-Transport.pdf
> >  
> >
> > Section 10.3.
> >
> > Some differences are:
> >
> > 1. There is one NTP packet stream per service, rather than the encoding
> > optimization in the hdr ext;
> > 2. RTCP SR records are emitted "near" video random access
> > points, rather than on a prescribed time schedule; and
> > 3. The above works in multicast-only, UDLR networks (e.g. television
> > broadcast), rather than requiring a 2-way link.
> >
> > #2 is interesting since in order to begin a *synchronized* decode (video
> > + audio properly correlated), a client must have acquired all of:
> > a. NTP
> > b. RTCP SR for each component
> > c. video reference frame and decoding metadata (i.e. a random access
> > point)
> > d. audio frame
> >
> > So, the relative timing of the RTCP SR records to the RTP stream content
> > is perhaps more important than the emission period.  Having the RTCP
> > SR records arrive faster than the video reference frames doesn't help of
> > course.  And even if they are "fast enough", having them
> > arrive out of sync with the reference frames delays the service
> > acquisition by half the period on average.
> >
> > Bandwidth utilization (how many bits to devote to RTCP and NTP) can
> > arguably be more efficiently managed by the server in most cases, not
> > individual client requests for faster RTCP SR packets. And, the client
> > would have no knowledge of the intended (video) reference frame periods
> > being used by the server, so it would not, in general, know what to ask
> > for.
> >
> > In practice, won't a server that wants to enable faster acquisition and
> > sync do things like the above?  I'm concerned that detailed requests
> > from clients beyond "please use more bandwidth and enable fast
> > sync" won't be as valuable as they seem since in the general case
> > the client doesn't know what to ask for exactly.
> >
> > FYI, the above ATSC document is in a "candidate" state where
> > public comments are solicited.  Independent of this thread, if
> > anyone has comments on it, I could convey them back to the ATSC.
> >
> > Regards,
> >
> >         Mike
> >
> > At 07:43 PM 3/9/2009 +0000, Colin Perkins wrote:
> > > The changes in this version are
> > > primarily editorial; we're aware that
> > > not all the open issues have been addressed yet. Any further
> > > comments
> > > are welcomed.
> > >
> > > Chairs: we'd like this to be considered as an AVT working group
> > > draft, as indicated privately.
> > >
> > > Cheers,
> > > Colin
> > >
> > >
> > >
> > >
> > > Begin forwarded message:
> > > > From:
> > > > Internet-Drafts at ietf.org
> > > > Date: 9 March 2009 17:15:02 GMT
> > > > To: i-d-announce at ietf.org
> > > > Subject: I-D Action:draft-perkins-avt-rapid-rtp-sync-03.txt
> > > > Reply-To: internet-drafts at ietf.org
> > > >
> > > > A New Internet-Draft is available from the on-line Internet-Drafts
> > > > directories.
> > > >
> > > >        
> > > > Title           : Rapid
> > > > Synchronisation of RTP Flows
> > > >        
> > > > Author(s)       : C. Perkins, T.
> > > > Schierl
> > > >        
> > > > Filename        :
> > > > draft-perkins-avt-rapid-rtp-sync-03.txt
> > > >        
> > > > Pages           :
> > > > 17
> > > >        
> > > > Date            :
> > > > 2009-03-09
> > > >
> > > > This memo outlines how RTP multimedia sessions are synchronised, and
> > > > discusses how rapidly such synchronisation can occur.  We show
> > > > that
> > > > most RTP sessions can be synchronised immediately, but that the use
> > > > of video switching multipoint conference units (MCUs) or large
> > > > source
> > > > specific multicast (SSM) groups can greatly increase the initial
> > > > synchronisation delay.  This increase in delay can be unacceptable
> > > > to
> > > > some applications that use layered and/or multi-description
> > > > codecs.
> > > >
> > > > This memo updates the RTP Control Protocol (RTCP) timing rules to
> > > > reduce the initial synchronisation delay for SSM sessions.  A
> > > > new
> > > > feedback packet is defined for use with the Extended RTP Profile for
> > > > RTCP-based Feedback (RTP/AVPF), allowing video switching MCUs to
> > > > rapidly request resynchronisation.  Two new RTP header extensions
> > > > are
> > > > defined to allow rapid synchronisation of late joiners, and
> > > > guarantee
> > > > correct timestamp based decoding order recovery for layered codecs
> > > > in
> > > > the presence of clock skew.
> > > >
> > > > A URL for this Internet-Draft is:
> > > > http://www.ietf.org/internet-drafts/draft-perkins-avt-rapid-rtp-
> > > > sync-03.txt
> > > >
> > > > Internet-Drafts are also available by anonymous FTP at:
> > > > ftp://ftp.ietf.org/internet-drafts/
> > > >
> > > > Below is the data which will enable a MIME compliant mail reader
> > > > implementation to automatically retrieve the ASCII version of the
> > > > Internet-Draft.
> > > > Content-Type: text/plain
> > > > Content-ID: <2009-03-09100610.I-D at ietf.org>
> > > >
> > > > _______________________________________________
> > > > I-D-Announce mailing list
> > > > I-D-Announce at ietf.org
> > > > https://www.ietf.org/mailman/listinfo/i-d-announce
> > > > Internet-Draft directories:
> > > >
> > > > http://www.ietf.org/shadow.html
> > > > or
> > > >
> > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > >
> > > _______________________________________________
> > > Audio/Video Transport Working Group
> > > avt at ietf.org
> > > https://www.ietf.org/mailman/listinfo/avt
> >
> > _______________________________________________
> > Audio/Video Transport Working Group
> > avt at ietf.org
> > https://www.ietf.org/mailman/listinfo/avt
>
> ---
> Visit us at
>
> Web 2.0 Expo / March 31 - April 03 / San Francisco, California / Booth
> 415
> http://www.web2expo.com/webexsf2009
>
> NAB SHOW 2009 / April 18-23 / Las Vegas, Nevada USA / South Hall (Upper),
> Booth SU9624F
> http://www.nabshow.com/