[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid-rtp-sync-03.txt
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/