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

From: Magnus Westerlund <[email-masked]>
Date: Mon, 16 Feb 2015 09:13:10 +0100

On 2015-01-30 03:34, Dale R. Worley wrote:
> Magnus Westerlund <[email-masked]> writes:
>> I need your input on this Errata. Should it be held for document update
>> or Rejected?
> 
> It's difficult to say because it's not clear (at least to me) what the
> erratum is intended to do.  I would need to see a more detailed
> explanation of the error the erratum is intended to correct.
> 

Hi,

There has been some off-line discussion with Julius around RFC2435 where
it becomes clear that he really like to have capabilities in the payload
format that the current specification does not support.

Therefore the decision is to reject this Errata.

Cheers

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: Julius Friedman <[email-masked]>
Date: Mon, 16 Feb 2015 03:51:50 -0500

Thank you.

And please, as per my final emails with Mr. Frederick, please do also see
if there is a way to indicate somehow that progressive images would need to
utilize a dynamic profile, the same for images which use components which
are non incremental or do not start at 0.

In short, the standard doesn't explicitly tell people that if you want to
do things like that you must use a dynamic profile.

Part of these desires I have came from the upset that the standard didn't
specify a standard way to use dynamic profiles, therefore even if I did
utilize a dynamic one the receiver would need to know how to handle the
format and kind of defeats the purpose of having a standard in the first
place.

If RFC2435 had been implemented as a dynamic profile of RFC2035 then it
possibly would have been easier to work around.

RFC2435 also specifically states progressive DCT would be supported in the
profile but unfortunately it cannot be supported unless a dynamic profile
is used or the DCT used is compatible with the interlaced DCT (coefficient
wise) making it a interlaced image anyway.

I suppose even though the Quantization tables are not in the correct order
that is because the RFC was only showing the tables, it would be up to
someone to put them into the ZigZag order as per the JPEG spec.

None the less, sorry for any confusion and I do appreciate your time.

Thanks!

---

From: "Frederick, Ron" <[email-masked]>
Date: Tue, 17 Feb 2015 20:42:12 +0000

Hi Julius,

On Feb 16, 2015, at 12:51 AM, Julius Friedman <[email-masked]> wrote:
> And please, as per my final emails with Mr. Frederick, please do also see if there is a way to indicate somehow that progressive images would need to utilize a dynamic profile, the same for images which use components which are non incremental or do not start at 0.
> 
> In short, the standard doesn't explicitly tell people that if you want to do things like that you must use a dynamic profile.

Do you have a suggestion for how the wording can be improved on this point? This is actually spelled out in the current RFCs. For instance, in RFC 2435 section 2, there is the following text:

   To maximize interoperability among hardware-based codecs, we assume
   the sequential DCT operating mode [1,Annex F] and restrict the set of
   predefined RTP/JPEG "type codes" (defined below) to single-scan,
   interleaved images.  While this is more restrictive than even
   baseline JPEG, many hardware implementation fall short of the
   baseline specification (e.g., most hardware cannot decode non-
   interleaved scans).

In section 4.1 it then goes on to say:

   Of the first group of fixed mappings, types 0 and 1 are currently
   defined, along with the corresponding types 64 and 65 that indicate
   the presence of restart markers.  They correspond to an abbreviated
   table-specification indicating the "Baseline DCT sequential" mode,
   8-bit samples, square pixels, three components in the YUV color
   space, standard Huffman tables as defined in [1, Annex K.3], and a
   single interleaved scan with a scan component selector indicating
   components 1, 2, and 3 in that order.  The Y, U, and V color planes
   correspond to component numbers 1, 2, and 3, respectively.  Component
   1 (i.e., the luminance plane) uses Huffman table number 0 and
   quantization table number 0 (defined below) and components 2 and 3
   (i.e., the chrominance planes) use Huffman table number 1 and
   quantization table number 1 (defined below).

This specifically states that only the baseline DCT sequential mode is supported (ruling out progressive DCT mode when using these predefined types) and also specifies the exact set of components, their numbering, and the mapping from them to the corresponding quantization and Huffman tables.

> Part of these desires I have came from the upset that the standard didn't specify a standard way to use dynamic profiles, therefore even if I did utilize a dynamic one the receiver would need to know how to handle the format and kind of defeats the purpose of having a standard in the first place.

This is the responsibility of a session setup protocol, as covered in the last sentence of section 3.1.3:

   The type field specifies the information that would otherwise be
   present in a JPEG abbreviated table-specification as well as the
   additional JFIF-style parameters not defined by JPEG.  Types 0-63 are
   reserved as fixed, well-known mappings to be defined by this document
   and future revisions of this document.  Types 64-127 are the same as
   types 0-63, except that restart markers are present in the JPEG data
   and a Restart Marker header appears immediately following the main
   JPEG header.  Types 128-255 are free to be dynamically defined by a
   session setup protocol (which is beyond the scope of this document).

> RFC2435 also specifically states progressive DCT would be supported in the profile but unfortunately it cannot be supported unless a dynamic profile is used or the DCT used is compatible with the interlaced DCT (coefficient wise) making it a interlaced image anyway.

We discussed this in our earlier e-mail exchange. The references in RFC 2435 are to the pre-defined types support “progressively scanned” image data, which is different from support for progressive DCT mode. Both progressive and interlaced images are supported, but the corresponding frames or interlaced fields are encoded independently, each as an entropy-coded segment containing a single JPEG scan using a subset of the baseline sequential DCT mode.

> I suppose even though the Quantization tables are not in the correct order that is because the RFC was only showing the tables, it would be up to someone to put them into the ZigZag order as per the JPEG spec.

I took a closer look at the sample code here, and the SendFrame() function that refers to these quantization tables is showing an example of how to format the RTP header data in the case where a dynamic Q value is used that requires that the tables be transmitted explicitly. In RTP, the quantization table data is NOT sent in zig-zag order, so I believe the sample code here is correct. If you have a custom quantization table coming from another source which is already in zig-zag order, this would need to be un-done before it is encoded in the RTP JPEG packet as in-band data.
-- 
Ron Frederick
[email-masked]

---

From: "Frederick, Ron" <[email-masked]>
Date: Tue, 17 Feb 2015 22:37:03 +0000

Sorry - a correction to the final point below in my previous reply:

> I took a closer look at the sample code here, and the SendFrame() function that refers to these quantization tables is showing an example of how to format the RTP header data in the case where a dy…

I was wrong about this. Section 3.1.8 does specify zig-zag order for these coefficients. So, while the code in Appendix A is not wrong by itself, the reference in Appendix B that suggests that the lqt & cqt parameters passed into it can be created using MakeTables() is not correct with its tables being in non zig-zag order and no re-ordering being applied before these tables are copied into the SOI segment.

Having MakeTables() in Appendix A produce a table which is already in zig-zag order is probably the simplest fix.
-- 
Ron Frederick
[email-masked]