Re: [AVTCORE] [Technical Errata Reported] RFC2435 (4097)

"Frederick, Ron" <ron.frederick@bluecoat.com> Wed, 28 January 2015 20:38 UTC

Return-Path: <ron.frederick@bluecoat.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08B3D1A0371 for <avt@ietfa.amsl.com>; Wed, 28 Jan 2015 12:38:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 5knMURUFaH7s for <avt@ietfa.amsl.com>; Wed, 28 Jan 2015 12:38:13 -0800 (PST)
Received: from plsvl-mailgw-02.bluecoat.com (plsvl-mailgw-02.bluecoat.com [199.91.133.12]) by ietfa.amsl.com (Postfix) with ESMTP id 785891A0389 for <avt@ietf.org>; Wed, 28 Jan 2015 12:38:13 -0800 (PST)
Received: from pwsvl-exchts-03.internal.cacheflow.com (pwsvl-exchts-03.bluecoat.com [10.2.2.160]) by plsvl-mailgw-02.bluecoat.com (Postfix) with ESMTP id 4698F200BF; Wed, 28 Jan 2015 12:38:13 -0800 (PST)
Received: from pwsvl-excmbx-05.internal.cacheflow.com ([fe80::f848:d461:9aa9:59a8]) by pwsvl-exchts-03.internal.cacheflow.com ([fe80::1ded:e21:ed06:fdc6%11]) with mapi id 14.03.0123.003; Wed, 28 Jan 2015 12:38:13 -0800
From: "Frederick, Ron" <ron.frederick@bluecoat.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Thread-Topic: [AVTCORE] [Technical Errata Reported] RFC2435 (4097)
Thread-Index: AQHQOxTJeHuTKICix0ivevGjR39yvZzWhJyA
Date: Wed, 28 Jan 2015 20:38:11 +0000
Message-ID: <D6E0A685-C106-42D4-BEF8-8B6BD664452E@bluecoat.com>
References: <20140904164839.0F554180450@rfc-editor.org> <54C9048F.1000509@ericsson.com>
In-Reply-To: <54C9048F.1000509@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.2.2.106]
Content-Type: multipart/alternative; boundary="_000_D6E0A685C10642D4BEF88B6BD664452Ebluecoatcom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/2ddFYes-Bfc8XaqecOfS5PA6uZg>
X-Mailman-Approved-At: Thu, 29 Jan 2015 05:11:23 -0800
Cc: "avt@ietf.org" <avt@ietf.org>
Subject: Re: [AVTCORE] [Technical Errata Reported] RFC2435 (4097)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Jan 2015 20:38:16 -0000

I agree with this. Here are some other issues:

- The “Original text” is actually wrong here. Both the width and height in the original text have a maximum of 2040 pixels. I’m guessing that the intent was to update this to 65535 for both width & height in the corrected text, but that would have been wrong as well. If I understand the proposal, the maximum supported value here would become 255*256, or 65280 pixels.

- I don’t understand how the receiving system is supposed to know whether the divisor is 8 or 256. Perhaps the text in the “Notes” was intended to somehow deal with this, but what’s proposed there doesn’t make sense to me. I also don’t see how this could be done in a manner which is backward compatible with existing clients.

- Using a larger divisor also has another problem. It would be impossible to represent image widths or heights greater than 2040 pixels that were not a multiple of 8. While we already have an issue with not being able to represent non-multiples of 8 in the current spec, that was done with the expectation that the JPEG block size would generally constrain images to 8x8, 16x8, or 16x16 size blocks, so that was not a strong requirement. Requiring larger sizes to always be a multiple of 256 seems like it would be much more problematic, and I think we need a better solution for that.

On Jan 28, 2015, at 7:47 AM, Magnus Westerlund <magnus.westerlund@ericsson.com<mailto:magnus.westerlund@ericsson.com>> wrote:

WG,

My proposal is that this Errata is "Rejected" based on that its section
of change does not contain any change. And the notes part proposed
changed is a redefinition of a field, i.e. something that would require
a replacement RFC to change.

Please provide any comments by the 12th of February.

Cheers

Magnus Westerlund
WG chair


On 2014-09-04 18:48, RFC Errata System wrote:
The following errata report has been submitted for RFC2435,
"RTP Payload Format for JPEG-compressed Video".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=2435&eid=4097

--------------------------------------
Type: Technical
Reported by: Julius Richard Friedman <juliusfriedman@gmail.com>

Section: 3.1.5

Original Text
-------------
3.1.5.  Width: 8 bits

  This field encodes the width of the image in 8-pixel multiples (e.g.,
  a width of 40 denotes an image 320 pixels wide).  The maximum width
  is 2040 pixels.

3.1.6.  Height: 8 bits

  This field encodes the height of the image in 8-pixel multiples
  (e.g., a height of 30 denotes an image 240 pixels tall). When
  encoding interlaced video, this is the height of a video field, since
  fields are individually JPEG encoded. The maximum height is 65535
  pixels.

Corrected Text
--------------
3.1.5.  Width: 8 bits

  This field encodes the width of the image in 8-pixel multiples (e.g.,
  a width of 40 denotes an image 320 pixels wide).  The maximum width
  is 2040 pixels.

3.1.6.  Height: 8 bits

  This field encodes the height of the image in 8-pixel multiples
  (e.g., a height of 30 denotes an image 240 pixels tall). When
  encoding interlaced video, this is the height of a video field, since
  fields are individually JPEG encoded. The maximum height is 65535
  pixels.

Notes
-----
Use a divisor of 256 to determine the height, where 8 / 256 = 32.

Ensure FragmentOffset does not exceed 2^24, if it does then use 2^24 - value)

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC2435 (no draft string recorded)
--------------------------------------
Title               : RTP Payload Format for JPEG-compressed Video
Publication Date    : October 1998
Author(s)           : L. Berc, W. Fenner, R. Frederick, S. McCanne, P. Stewart
Category            : PROPOSED STANDARD
Source              : Audio/Video Transport
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG
--
Ron Frederick
ronf@bluecoat.com<mailto:ronf@bluecoat.com>