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

["Frederick, Ron" <[e-mail]>]

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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]>

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
[e-mail]<mailto:[e-mail]>