Jaehwan Kim | 1 Apr 2007 10:48
Favicon

RE: Video streaming withour RTCP

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:matsui.yoshinori <at> jp.panasonic.com]
Sent: 2007-03-31 (토) 오전 12:11
To: annasagaram.vamsi <at> aftek.com; avt <at> ietf.org
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: <annasagaram.vamsi <at> aftek.com>
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
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt
annasagaram.vamsi | 1 Apr 2007 11:59
Favicon

RE: Video streaming withour RTCP

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:jaehwan <at> vidiator.com]
Sent: Sunday, April 01, 2007 2:18 PM
To: Y. Matsui; annasagaram.vamsi <at> aftek.com; avt <at> ietf.org
Subject: RE: [AVT] Video streaming withour RTCP

 

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:matsui.yoshinori <at> jp.panasonic.com]
Sent: 2007-03-31 () 오전 12:11
To: annasagaram.vamsi <at> aftek.com; avt <at> ietf.org
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: <annasagaram.vamsi <at> aftek.com>
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
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt
Colin Perkins | 1 Apr 2007 14:29

Re: AVC NALUs RTP packetisation

On 30 Mar 2007, at 11:38, Nikola Sprljan wrote:
...
> I guess what I'd like to ask this time is - is SSRC multiplexing gone
> for good, or there's still a chance it could be reconsidered?

I hope it's gone for good, since it gave the (false) impression that  
one could reliably adapt RTP streams without being in the signalling/ 
security context, and without buffering packets.

--

-- 
Colin Perkins
http://csperkins.org/

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt

Ross Finlayson | 1 Apr 2007 16:53
Favicon

RE: Video streaming withour RTCP

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/
_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt
Jaehwan Kim | 2 Apr 2007 00:04
Favicon

RE: Video streaming withour RTCP

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:finlayson <at> live555.com]
Sent: Sunday, April 01, 2007 11:54 PM
To: Jaehwan Kim
Cc: Y. Matsui; annasagaram.vamsi <at> aftek.com; avt <at> ietf.org
Subject: RE: [AVT] Video streaming withour RTCP

 

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/

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt
Coinchon, Mathias | 2 Apr 2007 08:33
Picon
Favicon

Parameters lost for media type MPA in new RFC4856 ?


Dear RFC editors,

I have one question regarding the new RFC4855 and RFC4856 that obsolete RFC3555:

- Where are parameters for MPA (mpeg audio) specified ? They were in RFC3555 (4.1.17) but not anymore in RFC4856.

As I have understood from RFC4855/4856, parameters should now be specified in payload format RFCs.
However looking in RFC2250 for MPEG payload format (video and audio) I don't see a specification of these parameters.
Looking on IANA pages, media type MPA still point on RFC3555.

Could you please tell me where to point now for MPEG audio parameters ?

Will there be modifications of RFC2250 for MPEG payload format specifying parameters ? (and modification of RFC3550/3551 to point to RFC3855/56 instead of RFC3555 ?)

This is an important issue as we rely and point to RFCs for the signalling of parameters (using SDP) for a standard on Audio contribution over IP (EBU group N/ACIP).

Thank you

Regards,

Mathias Coinchon
Senior Engineer
Technical Department

European Broadcasting Union
L'Ancienne-Route 17A
1218 Grand-Saconnex
Switzerland

Tel +41 22 717 27 16
Fax +41 22 747 47 16


************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify the system manager. This footnote also confirms that this email message has been swept by the mailgateway **************************************************

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt
Magnus Westerlund | 2 Apr 2007 09:05
Picon
Favicon

Re: Video streaming withour RTCP

Jaehwan Kim skrev:
> 
> 
> 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.

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: magnus.westerlund <at> ericsson.com
----------------------------------------------------------------------

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt

Ye-Kui.Wang | 2 Apr 2007 09:35
Picon

RE: AVC NALUs RTP packetisation

Confirmed that the SSRC multiplexing stuff has gone for good. The
original intention for that was to save number of fireware pinholes
and/or to enable stream adaptation when SRTP is in use. But it was later
found that there are no good use case. 

BR, YK 

>-----Original Message-----
>From: ext Colin Perkins [mailto:csp <at> csperkins.org] 
>Sent: Sunday, April 01, 2007 3:29 PM
>To: Nikola Sprljan
>Cc: Wang Ye-Kui (Nokia-NRC/Tampere); avt <at> ietf.org
>Subject: Re: [AVT] AVC NALUs RTP packetisation
>
>On 30 Mar 2007, at 11:38, Nikola Sprljan wrote:
>...
>> I guess what I'd like to ask this time is - is SSRC 
>multiplexing gone 
>> for good, or there's still a chance it could be reconsidered?
>
>I hope it's gone for good, since it gave the (false) 
>impression that one could reliably adapt RTP streams without 
>being in the signalling/ security context, and without 
>buffering packets.
>
>--
>Colin Perkins
>http://csperkins.org/
>
>
>

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt

Gaia Maselli | 2 Apr 2007 11:10
Picon

ACM/SIGMOBILE HEALTHNET 2007: Deadline is fast approaching!

(Apologies for multiple reception of this CFP)

**** DEADLINE APPROACHING ****
============================================================

                      Call for Papers

                ACM/SIGMOBILE HealthNet  2007

  The 1st International Workshop on Systems and Networking
   Support for Healthcare and Assisted Living Environments
              http://healthnet07.cs.uiuc.edu

             In conjunction with MobiSys 2007

                      June 11, 2007
                    Puerto Rico, USA

    EXTENDED DEADLINE: APRIL 6, 2007 (5PM US EST)

    Selected papers will be considered for fast track
      publication in a special issue of ACM Monet.

============================================================

WORKSHOP SCOPE:
================

As  the  world's  population  grows  older,  healthcare  and
high-tech companies are joining forces. New technologies are
being used to provide  improved support for elderly and home
bound  people   in  their  homes  and   in  assisted  living
environments. The  overall goal  of these initiatives  is to
improve the quality of  life by providing customized support
to people  in need of  assistance. The main challenge  is to
provide this  support according  to the user's  own specific
situation in  a non-intrusive and respectful  way. These new
technologies  enable the automation  of the  observation and
support for elderly and home bound people through the use of
sensors,  actuators,  distributed  intelligence,  databases,
ubiquitous  connectivity and  friendly  adaptive interfaces,
all connected  mainly via  a variety of  wireless networking
technologies. The  ultimate goal is a system  that can adapt
to  the users needs,  helping them  get through  their daily
routine  in a  way that  is effective  in  providing support
where  needed   without  making  them   feel  humiliated  by
excessive  attention. To  provide such  support, it  will be
necessary  to combine  efforts from  many areas  of computer
science,   including    networking,   distributed   systems,
security, data management, HCI, AI and middleware.

Given the inherent use  of mobile and wireless communication
and the  need for comprehensive distributed  systems as well
as the multi-disciplinary nature of solutions for healthcare
and assisted  living environments, the goal  of HealthNet is
to provide a forum for the cross-area interactions that will
be  necessary for successful  systems and  applications. The
specific focus of HealthNet will be on understanding what it
takes to provide effective systems and communication support
for  healthcare and  assisted living  environments. Although
the  systems  and  networking  community  is  very  good  at
providing  effective  solutions  to  satisfying  application
requirements,  they  require  input  from experts  in  other
disciples, including HCI,  middleware, security, privacy and
social networking, to  provide a more accurate understanding
of      the     specific     requirements      for     these
environments.   Therefore,   HealthNet   aims   to   attract
researchers working  on cross-disciplinary projects,  with a
focus  on understanding and  supporting the  requirements of
these complex applications.

Authors are invited to submit papers presenting new research
related  to the  support of  healthcare and  assisted living
environments.   All  submissions   must   describe  original
research,  not  published  or  currently  under  review  for
another workshop, conference, or journal.

Areas of interest include, but are not limited to:
* Enabling technologies
* Service and device discovery
* Security and privacy
* Reliability and fault tolerance
* User and device localization
* Resource management architecture
* User data management
* Middleware for heterogeneous networks
* Mobility and connectivity management
* Cross-layer system architecture design
* Human-centered Computing
* Task and behavior analysis
* Impact of user interface design on system design and
  management
* Test-beds and simulations environments

IMPORTANT DATES:
================

Paper submission deadline:              March 23, 2007
  ***** EXTENDED TO APRIL 6, 2007 (5PM US EST) ******
Notification of acceptance:                   April 27, 2007
Camera ready version due:                       May 17, 2007
Workshop date:                                 June 11, 2007

PAPER SUBMISSION INSTRUCTIONS:
===============================

All paper submissions will be handled electronically. Papers
must   be  in   PDF  format,   no  longer   than   6  pages,
double-column, with  a font size no smaller  than 10 points,
and must fit  properly on US Letter-sized paper  (8.5 inch x
11  inch) with reasonable  margins. The  first page  of each
paper  should  include the  names  and  affiliations of  the
authors, i.e.,  the submissions should not  be anonymous and
reviewing  is single-blind.  Submissions  will be  judged on
based on technical content and correctness, relevance to the
workshop, as well as presentation of the research.  Extended
versions of selected workshop  papers will be considered for
fast track publication in a special issue of ACM Monet.

ORGANIZING COMMITTEE
====================

WORKSHOP Co-Chairs:
  * Robin Kravets, University of Illinois, USA
  * Chiara Petrioli, Rome University "La Sapienza," Italy

PUBLICITY Co-Chairs:
  * Stefano Basagni, Northeastern University, USA
  * Gaia Maselli, Rome University "La Sapienza," Italy

TECHNICAL PROGRAM COMMITTEE
  * Amy Murphy, IRST-ITC
  * Archan Misra, IBM
  * Gene Tsudik, ISI
  * Hans Gellersen, Lancaster University
  * Henry Kautz, University of Rochester
  * Jack Stankovic, University of Virginia
  * Jean-Pierre Ebert, IHP Microelectronics
  * Karrie Karahalios, University of Illinois
  * Kay Connelly, Indiana University
  * Maria Ebling, IBM
  * Martha Pollack, University of Michigan
  * Nigel Davies, Lancaster University
  * Sunny Consolvo, Intel
  * Taieb Znati, University of Pittsburgh
  * Tarek Abdelzaher, University of Illinois
  * Wendi Heinzelman, University of Rochester
  * Yih-Chun Hu, University of Illinois

Please email  questions related  to paper submission  or the
technical program to: healthnet07 <at> cs.uiuc.edu.

Organized by UIUC and Rome University "La Sapienza".

--
Gaia Maselli, PhD
HealthNet 2007 Publicity Chair
Jaehwan Kim | 2 Apr 2007 12:10
Favicon

Why RTCP is needed for synch after long time in aggregated A/V RTSP session?

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:

Magnus wrote:
>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
Very nice references. Of course, Colin's is bible.

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

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt


Gmane