[Live-devel] RFC 2435 compliance

Alexandr Němec a.nemec at atlas.cz
Sun Dec 1 04:14:39 PST 2013


Hi Guy,
 
thanks for your posting. I understand your point, but I still think there is a problem with the RFC. Yes, appendix A says, that you can use the example code to compute a quantization table only (zigzag does not really matter), nothing wrong here. But later, in Appendix B it says (comment before MakeHeaders) that you can use the MakeTables routine from Appendix A to generate the quantization tables lqt and cqt as input for the MakeHeaders routine. Then, in MakeHeaders (MakeQuantHeader) "memcpy" is used to insert quantization table data into the JPEG header. And because Appendix B also says that MakeHeaders can be used to "generate a JPEG copressed image in interchange format", following these rules and instructions will lead to a corrupted JPEG image.
 
So what I want to say, it is just not possible to take all the RFC example code "as is" for a working implementation.
 
Best regards
 
Alex
______________________________________________________________
> Od: <Guy.Bonneau at miranda.com>
> Komu: "LIVE555 Streaming Media - development & use" <live-devel at ns.live555.com>
> Datum: 29.11.2013 20:35
> Předmět: Re: [Live-devel] RFC 2435 compliance
>
There is no issue with the RFC 2435 AppendixA neither with the live555 procedure to scale a quantization table witha Q factor.  Both are correct.. If you read the header of AppendixA it clearly states the reason of the example code :  "The following code can be used to create a quantization table froma Q factor..." Now when you recompute the quantization table froma selected Q factor your only scale the 64 quantization values by the samefactor. Doing the procedure on zigzag order on doing it on "standard"non-zigzag order doesn't matter. It will yield the same "scaled quantizationfactor". 

Jpeg encoding/decoding of spectral component of thepicture operate on block of 64 values. Those value must be processed inzigzag order. If you use a zigzaged table then the encoding/decoding onlyincrement the index of the quantization value in the table to get the goodquantization value. However if you use a non-zigzag table then the encoding/decodingmust find and pick-up the good quantization inside the table. This is upto the implementation of the code.

Guy Bonneau

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20131201/24480742/attachment.html>


More information about the live-devel mailing list