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

[Magnus Westerlund <[e-mail]>]

WG,

My decision is to recommend Rejected to the AD.

Cheers

Magnus Westerlund

On 2015-01-28 21:38, Frederick, Ron wrote:
> 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]>
> 
> 
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------