Subject: RE: [AVT] Video streaming withour RTCP

From: "Jaehwan Kim" <[email-masked]>
Date: Sun, 1 Apr 2007 17:48:09 +0900

Hi,
Yes. However, I found many players and servers couldn't handle some strings like "client_port=3122;server=12100".
Therefore, your application is good to have RTP/RTCP port pairs in the SETUP process. If so, supporting both RTP/RTCP seems not much difficult. 
 
As for sync, you can use RTP-Info and Range in RTSP. If it is live, although it is depends on the implementation of the peer, I receommend you support RTCP as well.
 
Regards,
Jaehwan

________________________________

From: Y. Matsui [mailto:[email-masked]]
Sent: 2007-03-31 (토) 오전 12:11
To: [email-masked]; [email-masked]
Subject: Re: [AVT] Video streaming withour RTCP

Hi,

RTSP is also available to synchronize audio and video in
streaming application, and it will be useful for control them
(play, pause, stop, etc.).

Best regards,

Yoshinori Matsui
Panasonic/Matsushita

----- Original Message -----
From: <[email-masked]>
Sent: Friday, March 30, 2007 10:11 PM
Subject: [AVT] Video streaming withour RTCP

> Hi,
> 
>     Can video(with audio) streaming is possible with out RTCP?  RTCP
> packets are used for lip sync. I suppose!!  If it is so, then with out RTCP
> how can we achieve audio & video that is lip sync.??
>
> Thanks & Regards,
> Vamsi

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: <[email-masked]>
Date: Sun, 1 Apr 2007 15:29:18 +0530

Hi, 

    Thanks for all these replies and suggestions.  I have developed RTP and RTCP but, due to some technical reasons I commented RTCP code as previously my application demanded only AUDIO.  And now I am about to implement even VIDEO.  For this I suppose it’s better to implement RTCP rather than going for other synchronization methods?? Can any one comment on this?  As per my understanding its better to use RTCP with RTP for synchronization of video and audio packets!!

Thanks & regards, 

Vamsi 

  _____  

From: Jaehwan Kim [mailto:[email-masked]] 
Sent: Sunday, April 01, 2007 2:18 PM
To: Y. Matsui; [email-masked]; [email-masked]
Subject: RE: [AVT] Video streaming withour RTCP

Hi,

Regards,

Jaehwan

  _____  

Hi,

Best regards,

Yoshinori Matsui
Panasonic/Matsushita

---

From: Ross Finlayson <[email-masked]>
Date: Sun, 1 Apr 2007 07:53:40 -0700

>As for sync, you can use RTP-Info and Range in RTSP.

No, this is appears to be a common misconception.  Although - when 
used in combination with the first RTCP "SR" report - the "RTP-Info" 
and "Range" headers can be used to generate an offset between 
presentation time and "NPT" (Normal Play Time), the "RTP-Info" and 
"Range" headers *alone* do not guarantee that you can get times (for 
audio and video) that remain synchronized *forever*.  For that, you 
need synchronized presentation times provided by RTCP.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

---

From: "Jaehwan Kim" <[email-masked]>
Date: Mon, 2 Apr 2007 07:04:32 +0900

Hi,

And could you explain more in detail?

I would appreciate if you give us an example.

If there is a common misconception happening again and again, IMO, the
notion with enough examples should be into RTSP specification.

Jaehwan

From: Ross Finlayson [mailto:[email-masked]] 
Sent: Sunday, April 01, 2007 11:54 PM
To: Jaehwan Kim
Cc: Y. Matsui; [email-masked]; [email-masked]
Subject: RE: [AVT] Video streaming withour RTCP

No, this is appears to be a common misconception.  Although - when used
in combination with the first RTCP "SR" report - the "RTP-Info" and
"Range" headers can be used to generate an offset between presentation
time and "NPT" (Normal Play Time), the "RTP-Info" and "Range" headers
*alone* do not guarantee that you can get times (for audio and video)
that remain synchronized *forever*.  For that, you need synchronized
presentation times provided by RTCP.

-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 02 Apr 2007 09:05:48 +0200

> notion with enough examples should be into RTSP specification.

Okay, we will log a request to clarify that RTP-Info only provides for 
initial sync and that RTCP is needed for maintaining sync in the case of 
clock drift. But there is much more on timestamp handling in 
http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-14
than what is in RFC 2326.

I could also recommend looking at the How To write RTP payload formats 
that has some discussion on the RTCP synch mechanism or Colin Perkins 
book on RTP.
http://tools.ietf.org/html/draft-ietf-avt-rtp-howto-01

There is also need to have RTCP for synch in cases such as multiple 
sources (SSRCs) and live sessions. In addition RTCP is needed for its 
transport monitoring purpose. The sender can't do any type of adaptation 
or avoid causing long term congestion unless RTCP is used.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Jaehwan Kim" <[email-masked]>
Date: Mon, 2 Apr 2007 19:10:57 +0900

Dear Magnus,
Yes, we need. And thanks to this group, people could learn many things
about RTP timestamp as described in the Appendix B of rfc2326bis. Now I
found most major players have been changed to follow it; it was not in
the past.

As for the subject, I would appreciate if we add more text about "why"
in future; I found one sentence from rfc2326bis-04 but failed to find
why.
(page92)

I felt that Ross knows some empirical knowledge. So, I asked him.
Ross, do you mind if you share your experience with us? 

>From my 2 cents, if the given RTSP session is VOD, although the given
session is enough long, the additional work, checking RTCP would not be
necessary to our client codes.

I think Ross mentioned the live RTSP session, in which we need to take
into account more. I would like to learn :->

And inline:

>http://tools.ietf.org/html/draft-ietf-avt-rtp-howto-01
Very nice references. Of course, Colin's is bible.

>or avoid causing long term congestion unless RTCP is used.
Sometimes, non-functional requirement like simplicity and modifiability
is more important than additional features. IMHO, thereby allowing an
applications using just RTP without RTCP would be meaningful. At least,
it looks like optional in rfc2326.

Cheers,
Jaehwan

---

From: "Greg Herlein" <[email-masked]>
Date: Mon, 2 Apr 2007 04:07:58 -0700

If we are going to add some language, I'd like to make sure we make a
clear point that RTCP provides the only standard way to get
*visibility* into the playback behavior (ie, packet loss rate etc) at
the end points.  Even if you don't plan to actively *use* that data
for stream control, it's very important to have that data for some
applications - and RTCP provides the standard way to get it.  I have
to explain this constantly to folks - more specific language about
"Why RTCP?" would be a good thing.

Greg