RTPbin property ts-offset-smoothing-factor has incorrect formula for averaging
I was reading the documentation for element rtpbin for version 1.22 and I think I noticed an error, at least there seems to be one in the documentation. I describe this below, and then give a suggestion on how ts-averaging could be made more useful when longer term averaging of the ts-offset is desired.
The potential bug is found within the property "ts-offset-smoothing-factor". The documentation says: Controls the weighting between previous and current timestamp offsets in a running moving average (RMA): ts_offset_average(n) = ((ts-offset-smoothing-factor - 1) * ts_offset_average(n - 1) + ts_offset(n)) / ts-offset-smoothing-factor
The forumla seems wrong to me. This is a simple linear combination of two quantities via a weighting factor: A = quantity one B = quantity two X = weighting factor C = weighted average of A and B The averaging formula should be written: C = AX + (1-X)B or you could also write: C = A(1-X) + BX
However, the formula shown in the documentation is in the form: C = A*(X-1) + BX The difference is in the (X-1) factor in the first term. That's incorrect. C should lie between A and B, but if X=0 we get C=A(0-1)+B*0, or C=-A. More specifically to the averaging of ts-offset, in the first part: ts_offset_average(n) = ((ts-offset-smoothing-factor - 1)... The factor (ts-offset-smoothing-factor - 1) is backwards and should be (1-ts-offset-smoothing-factor) given that 0 <= ts-offset-smoothing-factor <= 1.
I cannot see the actual code in which the ts-offset-smoothing-factor is implemented, so this may just be a documentation error, but the formula in the documentation will definitely cause problems if used.
SUGGESTED IMPROVEMENT FOR LONG-TERM AVERAGING OF TS-OFFSET If this formula is evaluated each frame there may be many, many evaluations per second. The cumulative effect over some time period is: X^n where X is the weighting factor and n is the number of evaluations that have passed in the time period of interest. Let's say we are handing audio at 48kHz in 1024 sample chunks. This means there are on the order of 40 frames per second. If X is 0.99 then in one second the moving average can change by 0.99^40 which equals about 0.67. In ten seconds this drops to 0.018. But the ts-offset is likely changing much, much slower than that. The problem is that the weighting factor is already almost at the slowest possible value limit of X=1-delta.
For slower averaging the user could be allowed to specify how many seconds the ts-offset should be averaged over, so that even in the smallest interval of 1 second (assuming parameter values less than 1 are reserved for the current moving average formula) there are 40 equally weighted ts-offset values. At the beginning of each frame, 1/40th of a second later, there is one new value added to the average and the oldest one dropped. You need to keep N values in memory to perform this sort of moving average, but the result will be MUCH smoother. Increasing the averaging interval to 10 or 100 seconds would allow much slower averaging that is possible with the current formula and might better correspond to the real-world rate of change of the ts-offset due to various sources of drift in the system.
Both the existing and my proposed averaging schemes could be implemented at the same time. The current moving average could be used when ts-offset-smoothing-factor < 1 and my proposed per-second averaging used when ts-offset-smoothing-factor >= 1