IETF Logo Mail Archive

Re: [MMUSIC] [AVTCORE] Question - Erratum 4097

"Frederick, Ron" <ron.frederick@bluecoat.com> Fri, 30 January 2015 05:11 UTC

Return-Path: <ron.frederick@bluecoat.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD9941A1B79; Thu, 29 Jan 2015 21:11:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.011
X-Spam-Level:
X-Spam-Status: No, score=-5.011 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-NS1ZHCn-gP; Thu, 29 Jan 2015 21:11:37 -0800 (PST)
Received: from plsvl-mailgw-01.bluecoat.com (spf.bluecoat.com [199.91.133.11]) by ietfa.amsl.com (Postfix) with ESMTP id E697D1A00F1; Thu, 29 Jan 2015 21:11:36 -0800 (PST)
Received: from PWSVL-EXCHTS-01.internal.cacheflow.com (unknown [10.2.2.122]) by plsvl-mailgw-01.bluecoat.com (Postfix) with ESMTP id 6FEB881A85B; Thu, 29 Jan 2015 21:11:36 -0800 (PST)
Received: from pwsvl-excmbx-05.internal.cacheflow.com ([fe80::f848:d461:9aa9:59a8]) by PWSVL-EXCHTS-01.internal.cacheflow.com ([fe80::5c50:e2ba:8115:4223%19]) with mapi id 14.03.0123.003; Thu, 29 Jan 2015 21:11:36 -0800
From: "Frederick, Ron" <ron.frederick@bluecoat.com>
To: "Dale R. Worley" <worley@ariadne.com>
Thread-Topic: [AVTCORE] [MMUSIC] Question - Erratum 4097
Thread-Index: AQHQPD7ngqiuZTiXpkOv6R37FVCa+ZzYpAuA
Date: Fri, 30 Jan 2015 05:11:34 +0000
Message-ID: <FF2A2B74-4A51-477F-ACA6-82FB9E3C615B@bluecoat.com>
References: <871tmdgch9.fsf@hobgoblin.ariadne.com>
In-Reply-To: <871tmdgch9.fsf@hobgoblin.ariadne.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [199.91.133.71]
Content-Type: text/plain; charset="utf-8"
Content-ID: <A493B92D069B694A9FFCEC5BA63F2E20@bluecoat.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/ZH70YpJusbmegy8XbiOwKDOhcho>
X-Mailman-Approved-At: Fri, 30 Jan 2015 09:32:49 -0800
Cc: Julius Friedman <juliusfriedman@gmail.com>, "avt@ietf.org" <avt@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] [AVTCORE] Question - Erratum 4097
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Jan 2015 05:11:42 -0000

On Jan 29, 2015, at 7:43 PM, Dale R. Worley <worley@ariadne.com> wrote:
> Julius Friedman <juliusfriedman@gmail.com> writes:
>> What about another divisor and or some text which states that if there is a
>> modulo that the frame height may have to be computed alternately?
> 
> I don't understand you here.  You seem to be proposing that another
> divisor for representing JPEG size be used, 256 rather than 8.  But that
> is an incompatible technical change.  In RFC 2435 there is not intended
> to be any alternative way to represent the frame height and width.

I agree with this. I don’t see any way in which the divisor could be changed in a backward compatible manner. A different encoding would need to be proposed to do this, and that can't be done as an errata of RFC 2435.

>> The fact that the image is incorrect makes this errata, the fact that the
>> verbiage in the RFC also allows for  via (RFC2435)
>> 
>> 4.1 <https://tools.ietf.org/html/rfc2435#section-4.1>.  The Type Field
>> 
>> Which makes this erratum because images which are advertised as supported
>> cannot be viewed or are distorted when the "reference" code is to be used
>> with such images and is NOT stated in the RFC....
>> 
>> Please advise.
> 
> As far as I can see, you mean to say that the RFC claims to be able to
> be able to transmit JPEGs that it cannot.  Can you explain this in more
> detail?  (My understanding is that the RFC provides an encoding method
> for *some* JPEGs, that the image data is a stream of JPEGs, but not all
> JPEGs can be used in RFC 2435 data streams.)

Mores specifically, the RFC only defines type values which allow you to encode YUV 4:2:2 and 4:2:0 JPEG images. It allows for the possibility of encoding images in other color spaces or with other sampling factors, but this would need to be done as an extension to RFC 2435 which defines these other items as new pre-defined type values, or by having an application use a dynamically defined type value in the range 128-255 (where both sender and receiver know how to interpret this dynamic value).
-- 
Ron Frederick
ronf@bluecoat.com

v2.23.0 | Report a Bug | By Email