Hello!
I am working on WebRTC - a framework for audio-video conferencing (or calls? In other words - real time communication). In this article I want to describe an interesting problem and how it was solved. In the problem, in fact, it was required to minimize the lcm of several real numbers with additional restrictions. I had to apply quite a bit of number theory or at least logic.
If you are only interested in the problem, then you can safely skip to the section "Formulation of the problem". The next section explains where it came from and what its meaning is.
Introduction
Clients can configure WebRTC to encode the incoming stream in multiple resolutions at once. For example, this can be useful in video conferencing: each client sends several streams to the server with different resolutions and bit rates, and the server sends to everyone else only the stream that fits in the bandwidth to the client.
But you can't just set the desired permissions, no — that would be too easy. The fact is that a source (for example, a camera in chrome) can produce video of any resolution. And there is also a feedback mechanism, and with a high load on the CPU, the incoming resolution decreases. In short, the user sets the scaling factors . Then the incoming frame is compressed a specified number of times, encoded and sent over the network to recipients.
The problem is that some encoders don't work with arbitrary images - they definitely need even sizes. And there are also all sorts of optimizations when encoding, if the resolution ratio for different images is whole. And most importantly, if different streams have different aspect ratios, then when switching between them there will be a very noticeable jerk. Therefore, it is necessary that the incoming resolution is completely divided by all coefficients.
, , : alignment
. , {1.0, 2.0, 4.0} , alignment=8
. - . , . , , 8 1, 2 4 , .
, {1, 1.7, 2.3}? , "" - 391. , 782. , , 782. , VGA (640x480) . - , , , -, , -, .
, , , ? , {1, 1.6, 2.4} {1, 1.7, 2.3} 48 ( 782). , .
:
:
:
: - , , .
, - -. . ( 16). - , .
- , (1), . i- .
, , . .
, :
(1) ,
( : ).
. , . ,
, (2) :
(3) :
, :
(3) (4):
, 1 ( ) :
, (1) (5) (6), , , . . (6) , .
. , , 0, . , 2 . , - , . . , (6).
, ( ):
const int kMaxAlignment = 16;
// scale_factor (S_i)
// (d) (A).
// error_acc.
float GetApprox(int encoder_alignment, int requested_alignment,
float scale_factor, float *error_acc) {
int k = static_cast<int> ((requested_alignment + 0.0) /
(encoder_alignment * scale_factor));
float best_error = 1e90;
float best_approx = 1.0;
for (int i = 0; i < 2; i++, k++) {
if (k == 0 || k * encoder_alignment > requested_alignment) continue;
float approx = (requested_alignment +0.0) / (k * encoder_alignment);
float error = (approx - scale_factor) * (approx - scale_factor);
if (error < best_error) {
best_error = error;
best_approx = approx;
}
}
*error_acc += best_error;
return best_approx;
}
// . (S'_i)
// (A) requested_alignment.
std::vector<float> CalulateAlignmentAndScaleFactors(
int encoder_alignment, std::vector<float> scale_factors,
int *requested_alignment) {
float best_error = 1e90;
int best_alignment = 1;
std::vector<float> best_factors;
std::vector<float> cur_factors;
for (int a = 1; a <= kMaxAlignment; ++a) {
float cur_error = 0;
cur_factors.clear();
for (float factor: scale_factors) {
float approx = GetApprox(encoder_alignment, a, factor, &cur_error);
cur_factors.push_back(approx);
}
if (cur_error < best_error) {
best_error = cur_error;
best_factors = cur_factors;
best_alignment = a;
}
}
*requested_alignment = best_alignment;
return best_factors;
}
, , . , . , .
Yes, without mathematics, you can still convince yourself that the coefficients issued by this code will fit the condition of the problem (the numerator divides the calculated alignment, so share everything entirely, and the denominator gives divisibility by the required alignment for the encoder). But without the chain of reasoning (1) => (4), (5) it is generally unclear how this code finds the optimal solution.