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

[Julius Friedman <[e-mail]>]

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? The issue
is also for black and white images and situations where 1 or more than 2
quantization tables were used.. I included samples of those images in the
initial email to the IETF which were from the JPEG test suite the W3C used
and I can re-attach them if required, there is nothing "special" about them
other than the fact that:

1) they are not sized correctly after depacketization due to the size
constraint which makes ANY image which is not sized in multiples of 8
either larger or smaller which DOES effect decoding quality.
2) they do not display correctly due to a missing table or a absent table.

The fact that the header is fixed can probably be used to the advantage to
either use the MBZ in such a case or the DRI fields if it's not being used
BUT I think that is more complex and IT DOES make it incompatible, if the
FragmentOffset is used like I stated it WILL be compatible with existing
implementations and no change will be required. I know that larger field is
desirable but the 'trick' used does allow compatibility and correctly
sorting the offsets and obtaining their correct value during this 'roll
over' which is unlikely as you stated anyway and thus only given for such
cases as those....

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.

On Fri, Jan 9, 2015 at 10:24 PM, Dale R. Worley <[e-mail]> wrote:

> Julius Friedman <[e-mail]> writes:
> > The RFC only provided a way for certain sized images much lower then what
> > JPEG supports to be transferred, this erratum fixes this by specifying
> that
> > in some cases you may need to use a different fraction to obtain the
> height
> > (which might not be in a multiple of 16 anyway) additionally it allows
> one
> > to deal with the nuance that if the data is so large that the
> > FragmentOffset will probably overflow during this time and provides a way
> > to deal with that as well.
>
> Whew, you're going to have to slow down here.  I'm not tracking what you
> say very well, but if I read it correctly, you're saying you want to
> change the divisor in sections 3.1.5 and 3.1.6 from 8 to 256.  Is that
> really correct?  And your justification seems to be that there are JPEGs
> that are so large that their sizes can't be represented within an 8 bit
> field with a multiplier of 8 (i.e., >2048).
>
> If so, this isn't an erratum, but a technical change, and it would have
> to go through the working group as an update to the RFC.  It would also
> be incompatible with every implementation that now uses this feature.
>
> In regard to "Fragment Offset", you seem to be allowing for JPEGs in
> excess of 2^24 bytes, which seems to me to be unlikely within the
> constraints of the existing height and width limitations.  In any case,
> reducing Fragment Offset modulo 2^24 would make reassembly of large
> frames ambiguous -- you'd really need a larger Fragment Offset field.
>
> What you're really asking for here is an RTP payload format much like
> RFC 2435 but different from it and incompatible with it.  That would be
> a new piece of work, as well as requiring assignment of a new "encoding
> name" so that control protocols could specify it.  (The "JPEG" encoding
> name is assigned to RFC 2435 media by RFC 3551 section 5.2.)
>
> Errata aren't for situations where "I think this protocol could have
> been designed better", but where the *text* doesn't express what the
> working group *meant*.
>
> Dale
>