Subject: [AVT] help @ measure quality(except MOS)

From: rahul agrawal <[email-masked]>
Date: Sat, 19 Mar 2005 10:42:39 +0000 (GMT)

sir/madam,
 
          i want to measure voice quality, so sir tell me methos (except MOS) tell me objective method, if there is any free software or any other alternative by which i can measure the voice quality and produce differentiate between them.
 
thanks

[email-masked] wrote:
Send avt mailing list submissions to
[email-masked]

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
[email-masked]

You can reach the person managing the list at
[email-masked]

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

Today's Topics:

1. Protocol Action: 'RTP Payload Format for Uncompressed Video'
to Proposed Standard (The IESG)
2. "RTP Payload format for uncompressed video" with ancillary
data (Alejandro Cabrera Obed)
3. "RTP Payload format for uncompressed video" with ancillary
data (Alejandro Cabrera Obed)

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

Message: 1
Date: Tue, 08 Mar 2005 09:33:34 -0500
From: The IESG 
Subject: [AVT] Protocol Action: 'RTP Payload Format for Uncompressed
Video' to Proposed Standard 
To: IETF-Announce 
Cc: avt chair , avt chair
, Internet Architecture Board , avt
mailing list , RFC Editor 
Message-ID: 

The IESG has approved the following document:

- 'RTP Payload Format for Uncompressed Video '
as a Proposed Standard

This document is the product of the Audio/Video Transport Working Group. 

The IESG contact persons are Allison Mankin and Jon Peterson.

* Technical Summary

This RTP payload format specifies a packetization scheme for 
encapsulating uncompressed video. It supports a range of standard- and 
high-definition video formats, including common television formats such 
as ITU BT.601, and standards from the Society of Motion Picture and 
Television Engineers (SMPTE), such as SMPTE 274M and SMPTE 296M. The 
format is designed to be applicable and extensible to new video 
formats as they are developed.

Uncompressed video formats may produces very high bandwidth streams
and therefore this format specifies a mandatory congestion control
procedure. 

* Working Group Summary

The WG supported the publication of this specification.

* Protocol Quality

This RTP payload format builds on the high bit-rate knowledge learned 
through RFC 3497 and otherwise uses common methods for RTP payload 
format design. The format has been implemented and also interoperability 
tested in the process of development. The document has been reviewed by
Philippe Gentric and Magnus Westerlund, and for the IESG by Allison Mankin.

* RFC Editor Notes

Section 6.1 MIME Type Registration

Encoding Considerations
OLD:
Uncompressed video can be transmitted with RTP as specified in RFC
XXXX. No file format is defined at this time.
NEW:
Uncompressed video is only transmitted over RTP as specified in RFC
XXXX. No file format media type has been defined to go with this 
transmission media type at this time.

OLD:
Magic number(s): None

File extension(s): None

Macintosh File Type Code(s): None
NEW:
Delete these three lines.

OLD:
Author/Change controller: Ladan Gharai 
NEW:
Author: Ladan Gharai 
Change Controller: IETF AVT Working Group
delegated from the IESG

Section 3, 1st paragraph:
OLD:

Each scan line of digital video is packetized into one or more RTP
packets. If the data for a complete scan line exceeds the network
MTU, the scan line SHOULD be fragmented into multiple RTP packets,
each smaller than the MTU. A single RTP packet MAY contain data for
more than one scan line. Only the active samples are included in the
RTP payload: inactive samples and the contents of horizontal and
vertical blanking SHOULD NOT be transported. Scan line numbers are
included in the RTP payload header, along with a field identifier for
interlaced video.

NEW:

Each scan line of digital video is packetized into one or more RTP
packets. If the data for a complete scan line exceeds the network
MTU, the scan line SHOULD be fragmented into multiple RTP packets,
each smaller than the MTU. A single RTP packet MAY contain data for
more than one scan line. Only the active samples are included in the
RTP payload: inactive samples and the contents of horizontal and
vertical blanking SHOULD NOT be transported. In instances where
ancillary data is being transmitted the sender and receiver can 
disambiguate between ancillary and video data via scan line numbers.
That is, the ancillary data will use scan line numbers that are not within 
the scope of the video frame.

Scan line numbers are included in the RTP payload header, along with 
a field identifier for interlaced video.

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

Message: 2
Date: Tue, 8 Mar 2005 13:48:56 -0300
From: Alejandro Cabrera Obed 
Subject: [AVT] "RTP Payload format for uncompressed video" with
ancillary data
To: AVT Lista 
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1

Dear all,

I've read the past mail about "RTP payload format for uncompressed
video" as a proposed standard. I'm studying the way to transmit HDTV
video uncompressed using this RFC, but I know that for the moment it´s
not possible to transmit both audio and video data with this RFC.

If I read this paragraph from the RFC: "In instances where ancillary
data is being transmitted the sender and receiver can disambiguate 
between ancillary and video data via scan line numbers. That is, the 
ancillary data will use scan line numbers that are not within the
scope of the video frame.", I ask you:

Is it possible to consider the audio data from the HDTV standard as
"ancillary data" and so transmit also the audio within the RTP Payload
format for uncompressed video with no synchronization problems with
the video data ???

Really thanks ,

Alejandro

-- 
Alejandro Cabrera Obed
[email-masked]

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

Message: 3
Date: Tue, 8 Mar 2005 13:48:56 -0300
From: Alejandro Cabrera Obed 
Subject: [AVT] "RTP Payload format for uncompressed video" with
ancillary data
To: AVT Lista 
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1

Dear all,

I've read the past mail about "RTP payload format for uncompressed
video" as a proposed standard. I'm studying the way to transmit HDTV
video uncompressed using this RFC, but I know that for the moment it´s
not possible to transmit both audio and video data with this RFC.

If I read this paragraph from the RFC: "In instances where ancillary
data is being transmitted the sender and receiver can disambiguate 
between ancillary and video data via scan line numbers. That is, the 
ancillary data will use scan line numbers that are not within the
scope of the video frame.", I ask you:

Is it possible to consider the audio data from the HDTV standard as
"ancillary data" and so transmit also the audio within the RTP Payload
format for uncompressed video with no synchronization problems with
the video data ???

Really thanks ,

Alejandro

-- 
Alejandro Cabrera Obed
[email-masked]

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

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

End of avt Digest, Vol 11, Issue 9
**********************************

---------------------------------
Do you Yahoo!?
 Yahoo! Small Business - Try our new resources site! 

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