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

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

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

On Feb 17, 2015, at 12:42 PM, Frederick, Ron <[e-mail]> wrote:
>> 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.

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
[e-mail]