The video encoders already have sophisticated bit rate control code that
can react to both stream reports sent by the client, and server frame
drop notifications. Furthermore they can adjust both the frame rate and
the image quality to best match the network conditions.
But if the client cannot se
Here are some pointers on ways to test this patch.
1. Tweaking the available bandwith at will
---
The point of the bit rate control algorithm is to adapt the video
stream's bitrate to the available network bandwidth. So you could test
how it reacts in v
On Thu, 27 Oct 2016, Francois Gouget wrote:
[...]
> Testing this you'll notice that reducing the available bandwidth results
> in freezes and recovery times that take a dozen second or more. This is
> because it's only after a sufficient backlog has been created (possibly
> a single large video
>
> The video encoders already have sophisticated bit rate control code that
> can react to both stream reports sent by the client, and server frame
> drop notifications. Furthermore they can adjust both the frame rate and
> the image quality to best match the network conditions.
>
> But if the c
>
> On Thu, 27 Oct 2016, Francois Gouget wrote:
> [...]
> > Testing this you'll notice that reducing the available bandwidth results
> > in freezes and recovery times that take a dozen second or more. This is
> > because it's only after a sufficient backlog has been created (possibly
> > a single
On Wed, 16 Nov 2016, Frediano Ziglio wrote:
[...]
> I don't know how much information can give the upper bound.
When the available bandwidth drops suddenly (e.g. degraded wifi / 3G
connection or multiple competing network streams starting) it can take
quite a few iterations before the video stre
On Wed, 16 Nov 2016, Frediano Ziglio wrote:
[...]
> Took me some time to test but the patch works as expected and
> video is smoother. Strangely seems that MJPEG works better than
> other encoders (beside taking more bandwidth).
Being curious I have to ask: how so?
(but I'll acknowledge that it ca
