<font size=2 face="sans-serif">There is no issue with the RFC 2435 Appendix
A neither with the live555 procedure to scale a quantization table with
a Q factor.  Both are correct.. If you read the header of Appendix
A it clearly states the reason of the example code : </font><tt><font size=2> 
"The following code can be used to create a quantization table from
a Q factor..." Now when you recompute the quantization table from
a selected Q factor your only scale the 64 quantization values by the same
factor. Doing the procedure on zigzag order on doing it on "standard"
non-zigzag order doesn't matter. It will yield the same "scaled quantization
factor". </font></tt>
<br>
<br><tt><font size=2>Jpeg encoding/decoding of spectral component of the
picture operate on block of 64 values. Those value must be processed in
zigzag order. If you use a zigzaged table then the encoding/decoding only
increment the index of the quantization value in the table to get the good
quantization value. However if you use a non-zigzag table then the encoding/decoding
must find and pick-up the good quantization inside the table. This is up
to the implementation of the code.</font></tt>
<br>
<br><tt><font size=2>Guy Bonneau <br>
</font></tt>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:      
 </font><font size=1 face="sans-serif">Alexandr Nìmec <a.nemec@atlas.cz></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:      
 </font><font size=1 face="sans-serif">LIVE555 Streaming Media
- development & use <live-devel@ns.live555.com>, </font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:      
 </font><font size=1 face="sans-serif">2013-11-25 07:06</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:    
   </font><font size=1 face="sans-serif">Re: [Live-devel]
RFC 2435 compliance</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Sent by:    
   </font><font size=1 face="sans-serif">live-devel-bounces@ns.live555.com</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>> This same question (I think) came up last January.
 Here is the answer that I gave at that time:<br>
 <br>
Thanks for your quick reply. Sorry, I googled through the archives, but
did not find this one. The "zigzag" idea is the correct answer,
as this order is required for the JPEG DQT segment. So Live555 is absolutely
correct here, but it turns out, that the code in Appendix A of RFC 2435
omits to use the reordered tables when creating jpeg headers, ie.
it contains a bug. I just could not believe that a RFC code example can
contain a bug.<br>
 <br>
Thanks.<br>
 <br>
Best regards<br>
 <br>
Alex<br>
_______________________________________________<br>
live-devel mailing list<br>
live-devel@lists.live555.com<br>
</font></tt><a href="http://lists.live555.com/mailman/listinfo/live-devel"><tt><font size=2>http://lists.live555.com/mailman/listinfo/live-devel</font></tt></a><tt><font size=2><br>
</font></tt>
<br><p>DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.</p>