[AVT] help about source codec(iLBC)

[rahul agrawal <[e-mail]>]

Please, help me.
                         i  get source codec (iLBC) from IETE site, but when i go to run it then some problem occur. it having many modules, so pls tell me that how should i run it, give me method to run this program.
 
 
one more query is that how coeffiecients vary in CELP, that is what is main criteria to change reflection coeffiecients of code book .
 
 
rahul agrawal
M.Tech (ELECTRONICS)

[e-mail] wrote:
Send avt mailing list submissions to
[e-mail]

To subscribe or unsubscribe via the World Wide Web, visit
https://www1.ietf.org/mailman/listinfo/avt
or, via email, send a message with subject or body 'help' to
[e-mail]

You can reach the person managing the list at
[e-mail]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of avt digest..."


Today's Topics:

1. Re: draft-ietf-avt-rtp-amr-bis-00.txt (Gorry Fairhurst)
2. RE: [dccp] TFRC applied to HDTV uncompressed 1.5 Gbps
(Phelan, Tom)
3. Re: [dccp] TFRC applied to HDTV uncompressed 1.5 Gbps
(Colin Perkins)
4. I-D ACTION:draft-ietf-avt-rtp-amrwbplus-03.txt
([e-mail])
5. I-D ACTION:draft-ietf-avt-rtp-bv-02.txt ([e-mail])
6. RE: Re: [dccp] TFRC applied to HDTV uncompressed 1.5 Gbps
(Ernesto Exposito)


----------------------------------------------------------------------

Message: 1
Date: Thu, 09 Dec 2004 16:50:38 +0000
From: Gorry Fairhurst 
Subject: Re: [AVT] draft-ietf-avt-rtp-amr-bis-00.txt
To: Magnus Westerlund 
Cc: "Johan Sj ? berg \(KI/EAB\)" ,
[e-mail]
Message-ID: 
Content-Type: text/plain; charset="US-ASCII"

I've numbered the issues, to try to help us quickly agree on what the
problem is/was.

On 9/12/04 10:18 am, "Magnus Westerlund" 
wrote:

> Hi Gorry,
> 
> I hope that you are aware that this draft is an update of RFC 3267,
> which mainly intends to fixes the lack of an offer-answer section.

Yes - and it seems a good application for UDP-Lite, which was what
interested me.

> However if we conclude that any of these normative text is wrong we
> should definitely consider changing it. But any backwards compatibility
> issues must be considered. The payload format is rather well deployed,
> however I think the CRC mode is very seldom or may be not at all used.
> Both the robust sorting and the CRC mode are specifically designed for
> UDP-Lite type of partial checksums.
> 
> I would also note that this format was finished long before UDP-Lite was
> approved and went through the last round of changes.

Yes - and if so, then it explains the differences.

On looking through your response, I wonder how much of my response is due to
there being two types of "frames" link-frame and payload-codec-frames, each
with their own CRC's. Normally I'd not expect RTP documents to mention link
frames, but use of UDP-Lite naturally leads to comments on link frames. If
this differentiation can be clearer, then the issues can be localised to
section 3.6.1 (which seems perhaps to be the correct place to discuss IP,
Link and UDP-Lite).

> See further below.
> 
> Gorry Fairhurst wrote:
>> 
>> I've just been doing a little reading of drafts from other WGs and had some
>> questions about the design rationale of the above ID:
>> 
>> 
>> I notice that in section 4.4.2.1, it says:
>> 
>> "The frame CRC, when used, MUST be calculated only over all class A
>> bits in the frame. Class B and C bits in the frame MUST NOT be
>> included in the CRC calculation and SHOULD NOT be covered by the
>> transport checksum."
>> 
>> I wonder if this could be justified?
>> 
>> At first read, this seems to go exactly the opposite way to what was
>> written
>> in UDP-Lite [RFC3828], section 4.
>> 
>> ...."For a link that supports
>> partial error detection, the Checksum Coverage field in the UDP-Lite
>> header MAY be used as a hint of where errors do not need to be
>> detected. Lower layers MUST use a strong error detection mechanism
>> [RFC-3819] to detect at least errors that occur in the sensitive part
>> of the packet, and discard damaged packets."
>> 
>> So my take on this was, UDP-Lite says you MUST perform a check on the IP
>> headers, and any fields covered by the Checksum coverage, but that you MAY
>> relax this to only cover the Checksum coverage for UDP-Lite frames. If
>> we're
>> changing the recommendation, then this introduces new issues that really
>> need
>> to be discussed.
>> 
> 
> I don't the text in section 4.4.2.1 that you quote is contradicting
> UDP-Lite at all.

OK - if that's the case, we can agree.

1) There's a subtle difference between what is expected Link behaviour as
described by UDP-Lite, and what this ID seems to suggest at the moment. This
lies in whether the Link-Layer does full frame protection; unequal
protection; or NO protection.

Experience with SLIP, etc, showed that NO protection of IP and transport
headers was bad - I would expect the concerns to be greater with IPv6 (where
there is no IP checksum), cite RFC3819 on use of link CRCs?

One thing I'd propose is to recommend a mode were all protocol headers up to
and including the class A bits in the frame are protected by a link-frame
CRC; you could cite UDP-Lite as clarification?

Would this impact any known usage? - Or is it only a clarification?

Of course, it is in practice hard for the IETF to mandate use of partial
(unequal) CRC protection at the link layer, never-the-less in my opinion, it
would be very wrong to encourage use of links with NO protection for IP.


2) Looking back, the current text in 3.6.1 seems to have a focus on RTP
issues (it is an AVT draft), but also touches on the implications for IP
networks. Perhaps a little more clarity here would prevent confusion (at
least for me). 

Suggestions are: Be clear which types of frame is being mentioned. It would
be good to mention the network and transport (i.e. UDP/UDP-Lite) headers
explicitly in your discussion. For example:

" 1) Utilizing a partial checksum to cover headers and the most
important speech bits of the payload."

Could become:
" 1) Utilizing a partial checksum to cover protocol headers (i.e., IP
network headers, UDP/UDP-Lite transport headers; RTP headers; and RTP
payload headers) together with the most important speech bits of the
payload."

Etc.

Is this what was meant?


> The CRC mode is specifically designed for partial
> checksums from the beginning. The bits in a AMR audio frame is sorted in
> sensitivity order, with the most sensitive bits first and the least
> last. This is utilized in circuit switched channel coding to provide
> three levels of protection A, which are so sensitive that any errors
> results in those bits not being used. A class B that has less protection
> but still needs lower bit-error rates than the class C bits that use the
> channel as is. The channel error rates are of course tuned to what the
> codec can accept in both bit-errors and frame erasures. Also if the
> class A bits are damaged as detected by the CRC (present also in the CS
> transport) some of the class B and C bits are used.
> 
This was what I thought, so that is good.

> Due to this characteristics of the codec, the CRC was included to
> provide maximum performance for RTP payload with multiple AMR frames.
> The per frame CRC allows the complete section of data frames to be
> unprotected by UDP-Lite. Bit-errors in the sensitive class A bits are
> detected by the CRC, and in that case the frame is marked as damaged and
> some of the B and C bits for that frame are used in concealment.
> 
Yes.
> The intention of the CRC mode compared to Robust sorting was to reduce
> the part that needs strong protection when aggregating multiple frames
> into a packet compared to the Robust Sorting mode. In the robust sorting
> mode, the complete payload data part is sorted byte-wise into decreasing
> order of sensitivity to bit-errors. In Robust sorting mode the intention
> is to cover the class A bits with the UDP-Lite checksum instead.
> 
> In conclusion I think this can be motivated.
> 
This sounds like the correct thing to do.
> 
>> Later, the ID also says:
>> 
>> "Packets SHOULD be discarded if the transport layer checksum detects
>> errors."
>> 
>> - Is there any justification why that is not a MUST be discarded, since the
>> check indicates the header IS mangled, and therefore there is little
>> confidence in using the packet header? Again it seems the opposite to
>> envisaged with UDP-Lite. Where UDP-Lite says, section 6:
>> 
>> ..."Corruption of any bit within
>> the protected area will then result in the IP receiver discarding the
>> UDP-Lite packet."
>> 
>> I'm not sure if this was a mistake or a design strategy. Can you tell me?
>> 
> 
> I am not certain why it says SHOULD rather than MUST. It was probably a
> case of given a little to much freedom to the implementors. In fact
> there are basically no fields where a bit-error could be present without
> resulting in serious problems for the playing application. Some
> bit-errors would result in inconsistent payload forcing one to discard
> it anyway. Others would result in misinterpretation of the result. For
> example a timestamp error would place the frame wrongly in time, which I
> consider quite serious. The backwards compatibility issues with changing
> this seem to be almost non-existent. If someone actually has taken on
> all the hassle to make an implementation that accept UDP-Lite packets
> with failed checksum and handles it correctly, fine they can keep it
> without affecting some else. The effect of the change would also only
> give the implementors a clearer implementation statement.
> 

3) Looking at the ID, I think the problem I had actually was in section 3.6
which speaks (I think) about Link-layer frames. If this was to be made
clear, then this section could refer back to it (and remove the potential
for confusion).

" The frame CRC, when used, MUST be calculated only over all class A
bits in the frame."

- Which "frame" is this about? - I think this is the payload-codec-frame of
RTP?

4) A correct UDP-Lite implementation MUST discard these packets (this is
also the way DCCP is expected to behave when using partial checksum
coverage). Of course AMR can also be used over non-IP transports, and then
you rely on their multiplexing and control functions to supply the bit
stream that AMR uses.

The rationale for IP transport was that allowing these packets to pass up
the stack with no verification of the IP header (in IPv6) or UDP-Lite header
(IPv4,IPv6), could result in cases of mis-delivery of arbitary corrupted
packets to *any* port, and applications do not generally have an ability to
handle such events robustly (with serious implications). So, unless there is
a strong argument, I'd recommend that if you use an IP network, you MUST use
a transport layer checksum.

> A better proposal may be to rewrite that sentence to simple note that
> any packets with errors detected by the UDP-Lite checksum or lower layer
> in that part will be discarded and never delivered.
> 

Exactly:-)

> Please provide more feedback if such a change is appropriate.
> 
> 
> Cheers
> 
> 
> Magnus Westerlund
> 
> Multimedia Technologies, Ericsson Research EAB/TVA/A
> ----------------------------------------------------------------------
> Ericsson AB | Phone [phone]
> Torshamsgatan 23 | Fax [phone]
> S-164 80 Stockholm, Sweden | mailto: [e-mail]
> 

I'm relieved we were closer than I thought... Are there still points of
disagreement?

Gorry





------------------------------

Message: 2
Date: Thu, 9 Dec 2004 13:41:11 -0500
From: "Phelan, Tom" 
Subject: [AVT] RE: [dccp] TFRC applied to HDTV uncompressed 1.5 Gbps
To: "Alejandro Cabrera Obed" , "AVT Lista"
, "DCCP Lista" 
Message-ID:

Content-Type: text/plain; charset="iso-8859-1"

Hi Alejandro,

See inline ...

Tom Phelan

> -----Original Message-----
> From: Alejandro Cabrera Obed [mailto:[e-mail]]
> Sent: Thursday, December 09, 2004 11:43 AM
> To: AVT Lista; DCCP Lista
> Subject: [dccp] TFRC applied to HDTV uncompressed 1.5 Gbps
> 
> 
> Dear people,
> 
> I'm from Argentina, developing a survey about HDTV uncompressed live
> streaming over IP. I'm contacting you in order to know what you think
> about applying TFRC to HDTV uncompressed live streaming (aprox. 1.5
> Gbps), in order to get congestion control.
> 
> 1) Do you think there is any limitation in applying the TFRC mechanism
> to my scenario ???

I think there's two issues you'll need to deal with. One is slow start - it'll take a good number of round trip times to get up to 1.5G bps. The other is, what will you do when there is congestion and you must reduce the transmit rate? I assume you'll be using large packets to get that high a transmit rate, so the small packet issues shown in http://www.phelan-4.com/dccp/tfrc-self-limit.pdf won't be a problem.

> 2) Is it correct the use of RTCP like a feedback mechanism for TFRC,
> taking the RTCP throughput at about 5% of 1.5 Gbps ???

Normally TFRC requires one feedback packet per RTT. So the RTCP 5% limit is a bit problematic. The feedback is greater or less than 5% depending on the RTT. I know this has been raised as a problem the RTP profile for TFRC - I'm not sure how Ladan has dealt with it. For DCCP, there's no such restriction. The DCCP feedback packets are fairly small - I don't remember the exact size, but using 40 bytes, you'd need an RTT of less than 5 microseconds to use up 5% of 1.5G on the feedback.

> 
> Maybe, if TRFC is OK to HDTV uncompressed, I'm interesting in studying
> into account the use of LSR and DLSR fields of RR in order to
> calculate the RTT.
> 
> Thanks a lot, I appreciate your opinion.
> 
> 
> Alejandro Cabrera Obed
> 
> _______________________________________________
> dccp IETF mailing list: [e-mail]
> list info: https://www1.ietf.org/mailman/listinfo/dccp
> wg charter: http://www.ietf.org/html.charters/dccp-charter.html
> 



------------------------------

Message: 3
Date: Thu, 9 Dec 2004 19:16:22 +0000
From: Colin Perkins 
Subject: [AVT] Re: [dccp] TFRC applied to HDTV uncompressed 1.5 Gbps
To: "Phelan, Tom" 
Cc: DCCP Lista , AVT Lista 
Message-ID: 
Content-Type: text/plain; charset=US-ASCII; format=flowed

You would also have the issue of how to maintain acceptable viewing 
quality whilst varying the transmission rate. That problem is at least 
as difficult as the practicalities of making the TFRC mechanisms work 
(and note that you must either compress or discard data to do this in 
real-time, so using TFRC for "uncompressed" HDTV isn't practical if 
there might be congestion).

Colin



On 9 Dec 2004, at 18:41, Phelan, Tom wrote:

> Hi Alejandro,
>
> See inline ...
>
> Tom Phelan
>
>> -----Original Message-----
>> From: Alejandro Cabrera Obed [mailto:[e-mail]]
>> Sent: Thursday, December 09, 2004 11:43 AM
>> To: AVT Lista; DCCP Lista
>> Subject: [dccp] TFRC applied to HDTV uncompressed 1.5 Gbps
>>
>>
>> Dear people,
>>
>> I'm from Argentina, developing a survey about HDTV uncompressed live
>> streaming over IP. I'm contacting you in order to know what you think
>> about applying TFRC to HDTV uncompressed live streaming (aprox. 1.5
>> Gbps), in order to get congestion control.
>>
>> 1) Do you think there is any limitation in applying the TFRC mechanism
>> to my scenario ???
>
> I think there's two issues you'll need to deal with. One is slow 
> start - it'll take a good number of round trip times to get up to 1.5G 
> bps. The other is, what will you do when there is congestion and you 
> must reduce the transmit rate? I assume you'll be using large packets 
> to get that high a transmit rate, so the small packet issues shown in 
> http://www.phelan-4.com/dccp/tfrc-self-limit.pdf won't be a problem.
>
>> 2) Is it correct the use of RTCP like a feedback mechanism for TFRC,
>> taking the RTCP throughput at about 5% of 1.5 Gbps ???
>
> Normally TFRC requires one feedback packet per RTT. So the RTCP 5% 
> limit is a bit problematic. The feedback is greater or less than 5% 
> depending on the RTT. I know this has been raised as a problem the 
> RTP profile for TFRC - I'm not sure how Ladan has dealt with it. For 
> DCCP, there's no such restriction. The DCCP feedback packets are 
> fairly small - I don't remember the exact size, but using 40 bytes, 
> you'd need an RTT of less than 5 microseconds to use up 5% of 1.5G on 
> the feedback.
>
>>
>> Maybe, if TRFC is OK to HDTV uncompressed, I'm interesting in studying
>> into account the use of LSR and DLSR fields of RR in order to
>> calculate the RTT.
>>
>> Thanks a lot, I appreciate your opinion.
>>
>>
>> Alejandro Cabrera Obed
>>
>> _______________________________________________
>> dccp IETF mailing list: [e-mail]
>> list info: https://www1.ietf.org/mailman/listinfo/dccp
>> wg charter: http://www.ietf.org/html.charters/dccp-charter.html




------------------------------

Message: 4
Date: Thu, 09 Dec 2004 15:43:57 -0500
From: [e-mail]
Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-amrwbplus-03.txt
To: [e-mail]
Cc: [e-mail]
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"

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 : Real-Time Transport Protocol (RTP) Payload Format for 
Extended AMR Wideband (AMR-WB+) Audio Codec
Author(s) : J. Sjoberg, et al.
Filename : draft-ietf-avt-rtp-amrwbplus-03.txt
Pages : 35
Date : 2004-12-9

This document specifies a real-time transport protocol (RTP) payload
format to be used for Extended AMR Wideband (AMR-WB+) encoded audio
signals. The AMR-WB+ codec is an audio extension of the AMR-WB codec
providing additional modes designed to give higher quality of music
and speech than the original modes. A MIME type registration is
included for AMR-WB+.

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] 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-amrwbplus-03.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


Internet-Drafts can also be obtained by e-mail.

Send a message to:
[e-mail].
In the body type:
"FILE /internet-drafts/draft-ietf-avt-rtp-amrwbplus-03.txt".

NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.


Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
-------------- next part --------------
Skipped content of type multipart/alternative

------------------------------

Message: 5
Date: Thu, 09 Dec 2004 15:44:02 -0500
From: [e-mail]
Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-bv-02.txt
To: [e-mail]
Cc: [e-mail]
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"

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 and Storage Format for BroadVoice Speech Codecs

=== message truncated ===
		
---------------------------------
Do you Yahoo!?
 Yahoo! Mail - 250MB free storage. Do more. Manage less.

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