[Live-devel] RFC 2435 compliance

[Guy.Bonneau at miranda.com]

I didn't looked at appendix B. But given that at page 7 of the RFC it is 
stated: "...Each table is an array of 64 values given in zig-zag order, 
identical to the format used in a JFIF DQT marker segment..." then I agree 
that it couldn't be possible to use all the code of the RFC specification. 
The fact that the quantization table is not zig-zag ordered lead to 
confusion.

Guy



From:   Alexandr Němec <a.nemec at atlas.cz>
To:     LIVE555 Streaming Media - development & use 
<live-devel at ns.live555.com>, 
Date:   2013-12-01 18:42
Subject:        Re: [Live-devel] RFC 2435 compliance
Sent by:        live-devel-bounces at ns.live555.com



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_______________________________________________
live-devel mailing list
live-devel at lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20131203/e051e204/attachment.html>