I just wanted to chime in here with my opinion as I had some experience with RFC2035 and RFC2435.
I am not sure the low contrast is related to the the clamping of the value in all cases. I also don't think that changing the value from 99 to 100 will effect anything as the quantization tables used when decoding are using tables which are already modified to be within the psyco-visual threshold and thus saturated from the ones given in the standard. The RFC is found @ https://tools.ietf.org/html/rfc2435 4.2. The Q Field For JPEG types 0 and 1 (and their corresponding types 64 and 65), Q values between 1 and 99 inclusive are defined as follows. Other values less than 128 are reserved. Additional types are encouraged to use this definition if applicable. Both type 0 and type 1 JPEG require two quantization tables. These tables are calculated as follows. For 1 <= Q <= 99, the Independent JPEG Group's formula [5] is used to produce a scale factor S as: S = 5000 / Q for 1 <= Q <= 50 = 200 - 2 * Q for 51 <= Q <= 99 Note that RFC2035 allowed values 1-128 to be specified for quality and thus this is what the clamping of the value is trying to ensure as when the value exceeds this threshold the quantization tables are included in the payload. @ https://www.ffmpeg.org/doxygen/trunk/rtpdec__jpeg_8c-source.html I think the contrast issues are more related to the check for which SEED value to use is slightly incorrect @ rtpdec_jpeg.c @ 00206 if (q < 50) Should be rtpdec_jpeg.c @ 00206 if (q <= 50) This would probably reduce the contrast of the image if the quality was exactly 50 because the seed value being used was intended for Quality values 51 - 99 resulting in a over-saturated image. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
