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

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

Hi Julius,

On Feb 16, 2015, at 12:51 AM, Julius Friedman <[e-mail]> 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
[e-mail]