На 06.07.11 19:08, Michal Svoboda написа:
Emil Ivov wrote:
You should bring both of those back to 100K. Again, the bandwidth param
does not cause less traffic to be generated. It simply delays traffic
that goes above the bandwidth cap and causes desync. The more you lower
the values in there, the more you would be causing desync.
Thanks, I'll try that.
So when the line simple can't send that much bps then the packets will
be lost and I should see smears on the video, is that correct?
We'll first buffer them for a while and start discarding them when that
buffer reaches a limit.
I thought the bandwidth limiter
would force down video quality and/or framerate to match the limit.
No. It only affects bandwidth. Nothing else.
I see. That's a little counter-intuitive for me.
It is indeed. Couldn't find a better name though.
Is there any practical
reason why it works this way? If the deal is that it needs to be at
least 100K then it seems to be of very little use
The bandwidth cap is meant as a solution to handling data bursts that
happen with key frames for example. If your home upstream bandwidth
allows for outgoing video to flow out undisturbed most of the time, you
are still likely to reach its limits when sending key frames (all the
more so with desktop sharing). In such cases a temporary desync is
better than artefacts and smearing.
The point of having a field that allows you to change the cap, is only
so that you could bring it up in case you'd like to have HD calls for
I see no adjustment knobs for the video quality, can that be altered?
Only by lowering resolution and fps.
Just out of curiosity: almost all video encoding applications derive the
video quality from a bps/average bps parameter. So how does Jitsi
determine the parameters for the encoder if not via bps?
Limiting frame rate and resolution has little to do with the encoder.
They simply regulate the size and the number of frames per second that
we are passing to it. The parameters would hence work regardless of what
codec is being used.