Em Sex, 2006-04-14 às 01:33 -0700, Trent Piepho escreveu:
> So anyway, here is my version of linear interpolation. It has a simpler
> formula in the code, and much better rounding behavior, as you can see in the
> plot here: http://www.speakeasy.org/~xyzzy/ber-snr.pngSounds good. I'll replace the corresponding parts at my code. May I
include your Signed-off-by at the patch?
>> static int ber_lut[][2] = {
> { 1.00 * 2047, 4798 },
> { 0.99 * 2047, 5380 },
> { 0.98 * 2047, 6032 },
> { 0.95 * 2047, 8502 },
> { 0.90 * 2047, 15066 },
> { 0.85 * 2047, 26696 },
> { 0.80 * 2047, 47306 },
> { 0.75 * 2047, 83826 },
> { 0.70 * 2047, 148539 },
> { 0.65 * 2047, 263210 },
> { 0.60 * 2047, 466406 },
> { 0.40 * 2047, 4598482 },
> { 0.30 * 2047, 14439082 } };
There is one remaining stuff: From the tests I did, BER next to 4798
generate a MPEG stream with errors on almost every block. So, the curve
(that were just the closest curve from the previous values) is not
representative, from users perspective, in terms of quality. I think we
should just drop the old values and create a more realistic curve,
since, from "Meaningful reporting of SNR", it seems that snr is being
used as a "quality indicator" without any linkage with the real SNR.
I guess the values of the curve are associated to SNR by a curve map.
Unfortunately, the public datasheet doesn't show this curve. Also, the
more relevant part to final user seems to be that ones from BER varying
from 1 to 5500, with is mapped as 100% (this is the values from the
original curve).
Going to userspace, very few variations on dB means high quality losses,
so, userspace applications need to do some conversions to make it
valuable to the user. Just showing SNR makes no sense to users.
Cheers,
Mauro.