Re: [RFC] [PATCH] Make S/N values to appear at cx24123 frontend

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Trent,

Em Sex, 2006-04-14 às 19:40 -0700, Trent Piepho escreveu:
> oN fRI, 14 Apr 2006, Mauro Carvalho Chehab wrote:
> > I've decided to use u64, instead of all those shifts. This way, we can
> > improve the precision for lower BER rates. Here, it worked like a charm:
> 
> It was only a single shift.  Anyway, the 64 bit math isn't being done
> correctly.  Here is a graph were you can see the problem clearly:
> http://www.speakeasy.org/~xyzzy/ber-error.png
Hmmm... I forgot the (s64) at the calculus :) I'll fix it. I think it is
better to make calculus with 64 bits to preserve precision, especially
for low BER rates.

> The comments about BER being 24-bit are wrong too.  If you look at the code to
> get BER, it's clearly a 22-bit value.
Those comments were the ones from the original driver.
> This means the table going up past 4
> million or so is pointless.  This is how the table is working:
> BER from 0 to about 5000 is linearly scaled to 100% to 99%
> BER from about 5000 to the maximum is log scaled to 99% to 40%

> I think it might be a good idea to revisit what exactly you want SNR to
> return.  Do you want SNR in dB scaled by some constant?  Or do you want
> something that even ranges from 0xffff for good to 0 for bad?

Yes, we should review the meaning of those index. The formula we are
using are just based on the ones from the original broken code.

About the meaning of BER, you may have an idea, looking at:
http://linuxtv.org/~mchehab/shot_ber_3870_sn_65064.png
This snap were taken with BER=3870 and SN=65064. the stream quality is
next to useless. Image were freezing, and several blocks lost. Still,
SNR is at 99,28% of the range.

IMHO, SNR should be associated to a value in dB, and a "quality" measure
to the user POV shoudn't be taken from SNR (or, at least, not only).

BER and UCB are better are better "quality loss" indicators, since they
are already linear and are directly associated with loss. What a
"quality indicator" may do (supposing that we have a device that really
measures SNR) is:

1) If UCB/BER=0 (or maybe UCB/BER less that 1 or 2), use SNR at a
"quality" range. Higher SNR will mean less change of having loss;

2) For UCB/BER>0(i.e. quality is already being compromised by a low
SNR), it can use, instead BER and/or UCB.

To, the indicator would do something like:
from 70% to 100%, BER=0, use SNR;
from 0% to 70%, use BER. 

Of course, for cx24123 code, we can't get SNR directly, but only
estimate it based on BER.

Cheers, 
Mauro.


_______________________________________________

linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[Index of Archives]     [Linux Media]     [Video 4 Linux]     [Asterisk]     [Samba]     [Xorg]     [Xfree86]     [Linux USB]

  Powered by Linux