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

From: Magnus Westerlund <[email-masked]>
Date: Wed, 28 Jan 2015 16:47:27 +0100

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 <[email-masked]>
> 
> 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
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
> 

-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Frederick, Ron" <[email-masked]>
Date: Wed, 28 Jan 2015 20:38:11 +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 <[email-masked]<mailto:[email-masked]>> wrote:

WG,

Cheers

Magnus Westerlund
WG chair

Section: 3.1.5

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

3.1.6.  Height: 8 bits

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

3.1.6.  Height: 8 bits

Notes
-----

Instructions:
-------------

Ron Frederick
[email-masked]<mailto:[email-masked]>