Multiparty Multimedia Session Control (mmusic)

Ingemar Johansson S | 1 Jun 2010 11:12

RTP timestamp and multiple sample rates

Hi

I have a faint memory that this question was raised before.
Suppose that we specify two audio codecs with different sample rates in the SDP

m=audio 54320 RTP/AVP 96 97
a=fmtp:96 AMR-WB/16000
a=fmtp:97 AMR-NB/8000

The sender can switch freely between the codecs and we assume that the decoder is smart enough to handle the switch.
The question the arise.. How do we know if the RTP TS value in the RTCP SR relates to  the 8000 or the 16000 sample
rate ?.
Can RFC 5576 be used in some intelligent way ?

/Ingemar

=================================
INGEMAR JOHANSSON  M.Sc. 
Senior Research Engineer 

Ericsson AB
Multimedia Technologies
Labratoriegränd 11
971 28, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
ingemar.s.johansson <at> ericsson.com
www.ericsson.com 
Visit http://labs.ericsson.com !
=================================

(Continue reading)

headers

Marc Petit-Huguenin | 1 Jun 2010 15:32

Re: [AVT] RTP timestamp and multiple sample rates


On 06/01/2010 02:12 AM, Ingemar Johansson S wrote:
> Hi
> 
> I have a faint memory that this question was raised before.
> Suppose that we specify two audio codecs with different sample rates in the SDP
> 
> m=audio 54320 RTP/AVP 96 97
> a=fmtp:96 AMR-WB/16000
> a=fmtp:97 AMR-NB/8000
> 
> The sender can switch freely between the codecs and we assume that the decoder is smart enough to handle the switch.
> The question the arise.. How do we know if the RTP TS value in the RTCP SR relates to  the 8000 or the 16000
sample rate ?.

Please have a look to the following I-D, that tries to answer that question:

https://datatracker.ietf.org/doc/draft-petithuguenin-avt-multiple-clock-rates/

See also the presentation at Anaheim:

http://www.ietf.org/proceedings/77/slides/avt-6.pdf

I plan to release another version after I received the results from the last SIPit.

> Can RFC 5576 be used in some intelligent way ?

--

-- 
Marc Petit-Huguenin
Personal email: marc <at> petit-huguenin.org

(Continue reading)

headers

Ingemar Johansson S | 2 Jun 2010 15:27

draft-ietf-mmusic-image-attributes, question regarding frame rate

Hi

First of all, thanks for all the comments on the image attribute draft. I will submit a new version at the end
of the week or early next week.

I received a question regarding frame rate . In an early version it was possible to specify a frame rate
range. See
http://tools.ietf.org/id/draft-johansson-mmusic-image-attributes-01.txt

For some reason this was removed but I don't anymore remember why. I recall that the reason was that, while
frame rate may have a meaning in older codecs such as H.261, it has less meaning for e.g H.264. Moreover the
"framerate" in H.264 is given by the level. But it is possible that my memory is totally off. 
Any comments around this are welcome

Regards
/Ingemar
=================================
INGEMAR JOHANSSON  M.Sc. 
Senior Research Engineer 

Ericsson AB
Multimedia Technologies
Labratoriegränd 11
971 28, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
ingemar.s.johansson <at> ericsson.com
www.ericsson.com 
Visit http://labs.ericsson.com !
=================================

(Continue reading)

headers

Ingemar Johansson S | 3 Jun 2010 08:39

Re: draft-ietf-mmusic-image-attributes, question regarding frame rate

Hi

Thanks for the reply
The frame rate was in the first individual submissions, but I later removed it after some discussion. But I
am inclined to agree, I don't believe that frame rate really fits here so I will not include frame rate in the draft.

Regards
Ingemar 

> -----Original Message-----
> From: Roni Even [mailto:Even.roni <at> huawei.com] 
> Sent: den 2 juni 2010 17:53
> To: Ingemar Johansson S; 'mmusic'
> Subject: RE: draft-ietf-mmusic-image-attributes, question 
> regarding frame rate
> 
> Hi,
> I am not sure that frame rate was in this draft. There is an 
> SDP attribute for frame rate see RFC 4566 section 6 a=framerate.
> 
> As for this draft, the motivation is to allow a receiver not 
> to scale the image and frame rate is not related to scaling 
> just the image size.
> 
> Roni Even
> 
> > -----Original Message-----
> > From: Ingemar Johansson S [mailto:ingemar.s.johansson <at> ericsson.com]
> > Sent: Wednesday, June 02, 2010 4:27 PM
> > To: mmusic

(Continue reading)

headers

Kyunghun Jung | 3 Jun 2010 08:53

Re: draft-ietf-mmusic-image-attributes, question regarding frame rate

Dear MMUSIC experts:

In fact, the primary application of "a=imageattr" considered then was point-to-point 3/4G mobile multimedia telephony

and in the typical cases of bit-rate fluctuation, quantizer or framerate would be controlled, rather than reducing the image size

since in most cases video decoder might not be able to handle such changes.

Kyunghun Jung

Samsung Electronics Co., Ltd.

------- Original Message-------
Sender: Ingemar Johansson S<ingemar.s.johansson <at> ericsson.com>
Date: 2010-06-03 15:39 (GMT+09:00)
Title: Re: [MMUSIC] draft-ietf-mmusic-image-attributes, question regarding frame rate

Hi

Thanks for the reply
The frame rate was in the first individual submissions, but I later removed it after some discussion. But I am inclined to agree, I don't believe that frame rate really fits here so I will not include frame rate in the draft.

Regards
Ingemar

> -----Original Message-----
> From: Roni Even [mailto:Even.roni <at> huawei.com]
> Sent: den 2 juni 2010 17:53
> To: Ingemar Johansson S; 'mmusic'
> Subject: RE: draft-ietf-mmusic-image-attributes, question
> regarding frame rate
>
> Hi,
> I am not sure that frame rate was in this draft. There is an
> SDP attribute for frame rate see RFC 4566 section 6 a=framerate.
>
> As for this draft, the motivation is to allow a receiver not
> to scale the image and frame rate is not related to scaling
> just the image size.
>
> Roni Even
>
> > -----Original Message-----
> > From: Ingemar Johansson S [mailto:ingemar.s.johansson <at> ericsson.com]
> > Sent: Wednesday, June 02, 2010 4:27 PM
> > To: mmusic
> > Cc: Roni Even; Ingemar Johansson S
> > Subject: draft-ietf-mmusic-image-attributes, question
> regarding frame
> > rate
> >
> > Hi
> >
> > First of all, thanks for all the comments on the image
> attribute draft.
> > I will submit a new version at the end of the week or early
> next week.
> >
> > I received a question regarding frame rate . In an early version it
> > was possible to specify a frame rate range. See
> >
> http://tools.ietf.org/id/draft-johansson-mmusic-image-attributes-01.tx
> > t
> >
> > For some reason this was removed but I don't anymore
> remember why. I
> > recall that the reason was that, while frame rate may have
> a meaning
> > in older codecs such as H.261, it has less meaning for e.g H.264.
> > Moreover the "framerate" in H.264 is given by the level. But it is
> > possible that my memory is totally off.
> > Any comments around this are welcome
> >
> > Regards
> > /Ingemar
> > =================================
> > INGEMAR JOHANSSON M.Sc.
> > Senior Research Engineer
> >
> > Ericsson AB
> > Multimedia Technologies
> > Labratoriegränd 11
> > 971 28, Luleå, Sweden
> > Phone +46-1071 43042
> > SMS/MMS +46-73 078 3289
> > ingemar.s.johansson <at> ericsson.com
> > www.ericsson.com
> > Visit http://labs.ericsson.com !
> > =================================
>
>
_______________________________________________
mmusic mailing list
mmusic <at> ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
mmusic <at> ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

headers

Internet-Drafts | 3 Jun 2010 10:45

I-D Action:draft-ietf-mmusic-image-attributes-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

	Title           : Negotiation of Generic Image Attributes in SDP
	Author(s)       : I. Johansson, K. Jung
	Filename        : draft-ietf-mmusic-image-attributes-05.txt
	Pages           : 23
	Date            : 2010-06-03

This document proposes a new generic session set up attribute to make
it possible to negotiate different image attributes such as image
size.  A possible use case is to make it possible for a low-end hand-
held terminal to display video without the need to rescale the image,
something that may consume large amounts of memory and processing
power.  The draft also helps to maintain an optimal bitrate for video
as only the image size that is desired by the receiver is
transmitted.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-image-attributes-05.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.

Attachment (draft-ietf-mmusic-image-attributes-05.txt): message/external-body, 70 bytes

_______________________________________________
mmusic mailing list
mmusic <at> ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

headers

Ingemar Johansson S | 3 Jun 2010 13:23

Re: [AVT] RTP timestamp and multiple sample rates

Hi

And thanks for refreshing my memory. It seems like when I read the draft that the most simple method is to use
the non-monothonic TS option. 

My interpretation of this is that it is necessary for the receiver to keep a list of the last received
timestamps and their associated sample rate for correct calculation. This list should of course be quite
small. Do I understand things correctly ?

/Ingemar

> -----Original Message-----
> From: Marc Petit-Huguenin [mailto:petithug <at> acm.org] 
> Sent: den 1 juni 2010 15:32
> To: Ingemar Johansson S
> Cc: avt <at> ietf.org; mmusic
> Subject: Re: [AVT] RTP timestamp and multiple sample rates
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 06/01/2010 02:12 AM, Ingemar Johansson S wrote:
> > Hi
> > 
> > I have a faint memory that this question was raised before.
> > Suppose that we specify two audio codecs with different 
> sample rates 
> > in the SDP
> > 
> > m=audio 54320 RTP/AVP 96 97
> > a=fmtp:96 AMR-WB/16000
> > a=fmtp:97 AMR-NB/8000
> > 
> > The sender can switch freely between the codecs and we 
> assume that the decoder is smart enough to handle the switch.
> > The question the arise.. How do we know if the RTP TS value 
> in the RTCP SR relates to  the 8000 or the 16000 sample rate ?.
> 
> Please have a look to the following I-D, that tries to answer 
> that question:
> 
> https://datatracker.ietf.org/doc/draft-petithuguenin-avt-multi
> ple-clock-rates/
> 
> See also the presentation at Anaheim:
> 
> http://www.ietf.org/proceedings/77/slides/avt-6.pdf
> 
> I plan to release another version after I received the 
> results from the last SIPit.
> 
> > Can RFC 5576 be used in some intelligent way ?
> 
> 
> - --
> Marc Petit-Huguenin
> Personal email: marc <at> petit-huguenin.org
> Professional email: petithug <at> acm.org
> Blog: http://blog.marc.petit-huguenin.org
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> 
> iEYEARECAAYFAkwFC9IACgkQ9RoMZyVa61epVwCeMix5XmnxfvmugsCqhZ2dniHF
> W5YAn35582fKqKM4mPIovE1Na+S3YBGm
> =sbLc
> -----END PGP SIGNATURE-----
>

headers

Roni Even | 3 Jun 2010 17:07

Re: draft-ietf-mmusic-image-attributes, question regarding frame rate

xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="" xmlns="http://www.w3.org/TR/REC-html40">

Samsung Enterprise Portal mySingle

Hi,

There are SDP parameters for this.

A= framerate

B= for bandwidth

A=quality for image quality

Roni Even

From: Kyunghun Jung [mailto:kyunghun.jung <at> samsung.com]
Sent: Thursday, June 03, 2010 9:53 AM
To: Ingemar Johansson S; Roni Even; 'mmusic'
Subject: Re: Re: [MMUSIC] draft-ietf-mmusic-image-attributes, question regarding frame rate

Dear MMUSIC experts:

In fact, the primary application of "a=imageattr" considered then was point-to-point 3/4G mobile multimedia telephony

and in the typical cases of bit-rate fluctuation, quantizer or framerate would be controlled, rather than reducing the image size

since in most cases video decoder might not be able to handle such changes.

Kyunghun Jung

Samsung Electronics Co., Ltd.

------- Original Message-------
Sender: Ingemar Johansson S<ingemar.s.johansson <at> ericsson.com>
Date: 2010-06-03 15:39 (GMT+09:00)
Title: Re: [MMUSIC] draft-ietf-mmusic-image-attributes, question regarding frame rate

Hi

Thanks for the reply
The frame rate was in the first individual submissions, but I later removed it after some discussion. But I am inclined to agree, I don't believe that frame rate really fits here so I will not include frame rate in the draft.

Regards
Ingemar

> -----Original Message-----
> From: Roni Even [mailto:Even.roni <at> huawei.com]
> Sent: den 2 juni 2010 17:53
> To: Ingemar Johansson S; 'mmusic'
> Subject: RE: draft-ietf-mmusic-image-attributes, question
> regarding frame rate
>
> Hi,
> I am not sure that frame rate was in this draft. There is an
> SDP attribute for frame rate see RFC 4566 section 6 a=framerate.
>
> As for this draft, the motivation is to allow a receiver not
> to scale the image and frame rate is not related to scaling
> just the image size.
>
> Roni Even
>
> > -----Original Message-----
> > From: Ingemar Johansson S [mailto:ingemar.s.johansson <at> ericsson.com]
> > Sent: Wednesday, June 02, 2010 4:27 PM
> > To: mmusic
> > Cc: Roni Even; Ingemar Johansson S
> > Subject: draft-ietf-mmusic-image-attributes, question
> regarding frame
> > rate
> >
> > Hi
> >
> > First of all, thanks for all the comments on the image
> attribute draft.
> > I will submit a new version at the end of the week or early
> next week.
> >
> > I received a question regarding frame rate . In an early version it
> > was possible to specify a frame rate range. See
> >
> http://tools.ietf.org/id/draft-johansson-mmusic-image-attributes-01.tx
> > t
> >
> > For some reason this was removed but I don't anymore
> remember why. I
> > recall that the reason was that, while frame rate may have
> a meaning
> > in older codecs such as H.261, it has less meaning for e.g H.264.
> > Moreover the "framerate" in H.264 is given by the level. But it is
> > possible that my memory is totally off.
> > Any comments around this are welcome
> >
> > Regards
> > /Ingemar
> > =================================
> > INGEMAR JOHANSSON M.Sc.
> > Senior Research Engineer
> >
> > Ericsson AB
> > Multimedia Technologies
> > Labratoriegränd 11
> > 971 28, Luleå, Sweden
> > Phone +46-1071 43042
> > SMS/MMS +46-73 078 3289
> > ingemar.s.johansson <at> ericsson.com
> > www.ericsson.com
> > Visit http://labs.ericsson.com !
> > =================================
>
>
_______________________________________________
mmusic mailing list
mmusic <at> ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
mmusic <at> ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

headers

Roni Even | 7 Jun 2010 11:19

SAVP and SAVP in draft-ietf-mmusic-rfc2326bis-23

Hi,

Section C.1.4 and C.1.5 recommend using MIKEY for key exchange. I think that since we now have DTLS-SRTP in RFC 5764 we should look at recommending this option.

Roni Even

_______________________________________________
mmusic mailing list
mmusic <at> ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

headers

Roni Even | 7 Jun 2010 11:03

RTCP in draft-ietf-mmusic-rfc2326bis-23

Hi,

In Section 10.5 it says

" RTCP: If RTP is used for media transport RTCP SHOULD be used."

Is there a case where RTCP is not used. RTCP is not optional according to RFC 3550. Why is this a SHOULD and not a MUST

Also in section C.1.2 I saw the following text:

o The RTCP/UDP packets from the server to the client MUST be sent to

the address and port given by the second address and port pair of

the "dest_addr" parameter. If no second pair is specified RTCP

MUST NOT be sent.

o The RTCP/UDP packets from the client to the server MUST be sent to

the address and port given by the second address and port pair of

the "src_addr" parameter. If no second pair is given RTCP MUST

NOT be sent.

Does this mean that you suggest sending RTP without RTCP. I would expect the same behavior as SDP m-line where if RTCP port is not specified it will be the RTP port+1 or the same if RTP/RTCP mux are used.

Roni Even

_______________________________________________
mmusic mailing list
mmusic <at> ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

221	May 2013
229	April 2013
228	March 2013
234	February 2013
96	January 2013
108	December 2012
152	November 2012
154	October 2012
109	September 2012
83	August 2012
61	July 2012
26	June 2012
18	May 2012
46	April 2012
103	March 2012
69	February 2012
23	January 2012
26	December 2011
61	November 2011
50	October 2011
53	September 2011
43	August 2011
56	July 2011
15	June 2011
42	May 2011
67	April 2011
96	March 2011
54	February 2011
25	January 2011
38	December 2010
53	November 2010
41	October 2010
71	September 2010
23	August 2010
22	July 2010
46	June 2010
41	May 2010
152	April 2010
81	March 2010
17	February 2010
15	January 2010
8	December 2009
27	November 2009
28	October 2009
29	September 2009
34	August 2009
55	July 2009
17	June 2009
24	May 2009
32	April 2009
61	March 2009
45	February 2009
18	January 2009
72	December 2008
81	November 2008
76	October 2008
30	September 2008
47	August 2008
131	July 2008
46	June 2008
61	May 2008
63	April 2008
96	March 2008
151	February 2008
36	January 2008
39	December 2007
127	November 2007
74	October 2007
47	September 2007
60	August 2007
257	July 2007
132	June 2007
96	May 2007
212	April 2007
233	March 2007
72	February 2007
100	January 2007
79	December 2006
170	November 2006
169	October 2006
137	September 2006
82	August 2006
122	July 2006
103	June 2006
60	May 2006
59	April 2006
118	March 2006
49	February 2006
51	January 2006
28	December 2005
91	November 2005
74	October 2005
47	September 2005
61	August 2005
105	July 2005
56	June 2005
29	May 2005
15	April 2005
48	March 2005
92	February 2005
70	January 2005
109	December 2004
49	November 2004
83	October 2004
58	September 2004
82	August 2004
196	July 2004
96	June 2004
64	May 2004
40	April 2004
52	March 2004
56	February 2004
39	January 2004
63	December 2003
106	November 2003
123	October 2003
114	September 2003
56	August 2003
199	July 2003
94	June 2003
84	May 2003
91	April 2003
78	March 2003
86	February 2003
41	January 2003
40	December 2002
75	November 2002
91	October 2002
45	September 2002
44	August 2002
107	July 2002
62	June 2002
107	May 2002
99	April 2002

Mon	Tue	Wed	Thu	Fri	Sat	Sun

	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30