headers
Internet-Drafts | 1 Dec 2005 21:50
Picon
Favicon

I-D ACTION:draft-ietf-avt-rfc2833biscas-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.

	Title		: Definition of Events For Channel-Oriented Telephony Signalling
	Author(s)	: T. Taylor, H. Schulzrinne
	Filename	: draft-ietf-avt-rfc2833biscas-01.txt
	Pages		: 24
	Date		: 2005-12-1
	
This memo updates RFC xxxx (currently draft-ietf-avt-rfc2833bis-12)
   to add event codes for telephony signals used for channel-associated
   signalling when carried in the telephony event RTP payload.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2833biscas-01.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-avt-rfc2833biscas-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 2 Dec 2005 00:50
Picon
Favicon

I-D ACTION:draft-ietf-avt-ulp-13.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.

	Title		: An RTP Payload Format for Generic FEC
	Author(s)	: A. Li
	Filename	: draft-ietf-avt-ulp-13.txt
	Pages		: 44
	Date		: 2005-12-1
	
This document specifies a payload format for generic Forward
   Error Correction (FEC) for media data encapsulated in RTP. It is
   based on the exclusive-or (parity) operation, and it is a
   generalized algorithms that includes Uneven Level Protection
   (ULP). The payload format described in this draft allows end
   systems to apply protection using arbitrary protection lengths
   and levels, in addition to using arbitrary protection group
   sizes. It enables complete recovery or partial recovery of the
   critical payload and RTP header fields depending on the packet
   loss situation. This scheme is completely backward compatible
   with non-FEC capable hosts. Those receivers that do not know
   about FEC can simply ignore the protection data. This
   specification obsoletes RFC 2733 and RFC 3009.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-ulp-13.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andrea Lorenzo VITALI | 2 Dec 2005 11:35

Re: Sigalling for layered media -- do it generic or do itpayloadspecific


> I am in the opinion that a middlebox as well as a receiver has to have the
> full knowledge about the media and therefore it must be able to parse all
> binary SVC description. But it could make life easier if the
> dependency/relation would be signalled via e.g. extended group-semantics.
> But for SVC there is no strong demand on doing signalling in a generic way.

This is a good summary of available alternatives. Let me recap:
1) middlebox able to parse all binary description -> impractical
2) extended group-semantic (RFC 3388)
3) nothing -> not acceptable

Let me add that there is not only layered or scalable coding (SVC) but 
also other coding techniques as multiple description coding (MDC).

The 1st option is impractical. Middleboxes should be as simple as possible.

The 3rd option is not acceptable. It is easy indeed. But it does not 
exploit available features. E.g. dropping the least important layer 
(SVC) or one description (MDC).

The 2nd option is viable. Not easy, but also not impossible to do.

Wenger suggested a simple generic technique to signal dependency among 
layers in draft-wenger-avt-rtp-svc-00.txt

The technique was based on tagging layers and on signalling for each 
layer the "parent" layer. This works for SVC where each layer has only 
one parent layer. The base layer havo no parent. For your convenient I 
enclose here the example of Wenger (slide #9):
(Continue reading)

Permalink | Reply | 16 comments |
headers
Thomas Schierl | 2 Dec 2005 17:22
Picon
Picon

RE: Sigalling for layered media -- do it generic or do itpayloadspecific

Andrea,

What I tried to say is, we could signal the dependency within SDP in a
generic way, but in the case of SVC that would be redundant information
since for SVC more detailed knowledge of the stream will be required for
doing real useful things like shown in the slides of Stephan.
In my opinion MDC is no reason for having generic signalling. Since there is
neither an international standard nor a widely accepted solution for MDC
available, instead of that basically different approaches are proposed
within research papers. Sorry, but I don't expect anything being
standardized in the next years. But that's my opinion only! Let us ask the
other people.

Nevertheless, there could be a reason doing the generic signalling also for
JPEG2000.
I want to ask this question now, better than having discussions too late in
the standardization process of the SVC payload format.
I'm not an expert with JPEG2000, but I want to ask the people working on
that draft:
Does it make sense to signal a layer dependency for JPEG2000 in a generic
way? 
If the answer should be YES, then we would have two codecs, which have
similar properties and could be used in a similar way. Thus generic
signalling could be useful.
Anyway extending the "group-semantics" would be enough for SVC and hopefully
for JPEG2000 as well.
But if the answer is NO, I can see no other use-cases, in which today's
scalable video codecs would strongly require the generic SDP signalling.

Thomas.
(Continue reading)

Permalink | Reply | 15 comments |
headers
Holmes,David A | 2 Dec 2005 18:01

RE: Sigalling for layered media -- do it genericor do itpayloadspecific

This may seem like a minor detail, but while an English dictionary contains both spellings of "signalling"
and "signaling", the commonly used spelling (e.g., IEEE Communications Magazine papers) in computer
networking literature is "signaling".

David

-----Original Message-----
From: avt-bounces <at> ietf.org [mailto:avt-bounces <at> ietf.org]On Behalf Of
Thomas Schierl
Sent: Friday, December 02, 2005 8:23 AM
To: 'Andrea Lorenzo VITALI'
Cc: itakura <at> sm.sony.co.jp; 'Magnus Westerlund';
andrew.leung <at> jp.sony.com; 'Stephen Casner'; 'AVT WG'; 'Colin Perkins';
satosi-f <at> sm.sony.co.jp
Subject: RE: [AVT] Sigalling for layered media -- do it genericor do
itpayloadspecific

Andrea,

What I tried to say is, we could signal the dependency within SDP in a
generic way, but in the case of SVC that would be redundant information
since for SVC more detailed knowledge of the stream will be required for
doing real useful things like shown in the slides of Stephan.
In my opinion MDC is no reason for having generic signalling. Since there is
neither an international standard nor a widely accepted solution for MDC
available, instead of that basically different approaches are proposed
within research papers. Sorry, but I don't expect anything being
standardized in the next years. But that's my opinion only! Let us ask the
other people.
(Continue reading)

Permalink | Reply | 1 comment |
headers
The IESG | 2 Dec 2005 18:00
Picon
Favicon

Last Call: 'Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate Multimode Wideband (VMR-WB) Extension Audio Codec' to Proposed Standard

The IESG has received a request from the Audio/Video Transport WG to consider 
the following document:

- 'Real-Time Transport Protocol (RTP) Payload Format for the Variable-Rate 
   Multimode Wideband (VMR-WB) Extension Audio Codec '
   <draft-ietf-avt-rtp-vmr-wb-extension-02.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg <at> ietf.org or ietf <at> ietf.org mailing lists by 2005-12-16.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-vmr-wb-extension-02.txt

_______________________________________________
IETF-Announce mailing list
IETF-Announce <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce
Permalink | Reply | 0 comments |
headers
Tom-PT Taylor | 2 Dec 2005 18:21
Favicon

Re: Sigalling for layered media -- do it genericor do itpayloadspecific

Depends where you come from.  "Signalling" in Canada and Britain.

Holmes,David A wrote:
> This may seem like a minor detail, but while an English dictionary contains both spellings of
"signalling" and "signaling", the commonly used spelling (e.g., IEEE Communications Magazine papers)
in computer networking literature is "signaling".
> 
> David
> 
> -----Original Message-----
> From: avt-bounces <at> ietf.org [mailto:avt-bounces <at> ietf.org]On Behalf Of
> Thomas Schierl
> Sent: Friday, December 02, 2005 8:23 AM
> To: 'Andrea Lorenzo VITALI'
> Cc: itakura <at> sm.sony.co.jp; 'Magnus Westerlund';
> andrew.leung <at> jp.sony.com; 'Stephen Casner'; 'AVT WG'; 'Colin Perkins';
> satosi-f <at> sm.sony.co.jp
> Subject: RE: [AVT] Sigalling for layered media -- do it genericor do
> itpayloadspecific
> 
> 
> Andrea,
> 
> What I tried to say is, we could signal the dependency within SDP in a
> generic way, but in the case of SVC that would be redundant information
> since for SVC more detailed knowledge of the stream will be required for
> doing real useful things like shown in the slides of Stephan.
> In my opinion MDC is no reason for having generic signalling. Since there is
> neither an international standard nor a widely accepted solution for MDC
> available, instead of that basically different approaches are proposed
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrea Lorenzo VITALI | 2 Dec 2005 18:36

Re: Sigalling for layered media -- do it generic or do itpayloadspecific


> What I tried to say is, we could signal the dependency within SDP in a
> generic way, but in the case of SVC that would be redundant information

Ok. I got your point. The same information (dependency) would be sent 
twice. Out-of-band via SDP and in-band in the bitstream.

However, let's say that we want to do packet dropping because of 
congestion. It would indeed be useful to have middlebox capable of 
dropping the least important packets (packets in the enhancement layer). 
And this middlebox should not be SVC-aware. Right? Or am I missing some 
point?

> In my opinion MDC is no reason for having generic signalling. Since there is
> neither an international standard nor a widely accepted solution for MDC

You are completely right. And that's why we want to propose a 
standard-compatible MDC approach done in the pixel domain. It could be 
easily standardized as it is not codec-dependent.

SVC gives you efficient scalability. MDC gives you error-resilience. It 
would be good to have the best of both.

With standard-compatible MDC you create subsequences that can then be 
coded in a scalable way, eg. using SVC. Remember that SVC is also 
backward compatible because the base layer is a standard H.264 stream.

While pushing for MDC we believe to be in the same track as SVC.

> Does it make sense to signal a layer dependency for JPEG2000 in a generic
(Continue reading)

Permalink | Reply | 14 comments |
headers
Internet-Drafts | 2 Dec 2005 21:50
Picon
Favicon

I-D ACTION:draft-ietf-avt-rtp-atrac-family-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.

	Title		: RTP Payload Format for ATRAC Family
	Author(s)	: M. Romaine, et al.
	Filename	: draft-ietf-avt-rtp-atrac-family-05.txt
	Pages		: 26
	Date		: 2005-12-2
	
This document describes an RTP payload format for efficient and
   flexible transporting of audio data encoded with the Adaptive
   TRansform Audio Codec (ATRAC) family of codecs.  Recent enhancements
   to the ATRAC family of codecs support high quality audio coding with
   multiple channels.  The RTP payload format as presented in this
   document also includes support for data fragmentation, elementary
   redundancy measures, and a variation on scalable streaming.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-atrac-family-05.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-avt-rtp-atrac-family-05.txt".
(Continue reading)

Permalink | Reply | 0 comments |
headers
Colin Perkins | 3 Dec 2005 17:17

Re: [Fwd: I-DACTION:draft-sollaud-avt-rtp-g729-scal-wb-ext-02.txt]

On 22 Nov 2005, at 00:01, Colin Perkins wrote:
> On 18 Nov 2005, at 08:59, SOLLAUD Aurelien RD-TECH-LAN wrote:
>> This I-D specifies the RTP payload format and media type registration
>> for the future scalable and wideband extension of the G.729 audio  
>> codec.
>> This extension is  also known as G.729EV.
>>
>> The codec development is in its final stage, and it should be  
>> approved
>> by the ITU-T in April 2006. So I would appreciate reviews and  
>> comments,
>
> The simplifications compared to the previous version look  
> appropriate. I think this is coming along nicely.
>
>> and propose it to be taken as a WG item.
>
> This is clearly within the scope of AVT, should the group approve  
> it. Are there any objections from the working group? If so, please  
> comment to the list by 2nd December. If there are no objections,  
> we'll take this as a working group draft.

There were no objections, so this draft is now taken as an AVT work  
item.

Colin

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
(Continue reading)

Permalink | Reply | 1 comment |

Gmane