[jitsi-dev] Bandwidth Issues


#1

Hi,

yesterday I had a nice test session with two Jitsis and then again on the same machines and networks with another, proprietary - rather spooky but nevertheless very popular - communication system. This has been an interesting comparison I've never had before with any of my Open Source VoIP systems.

Anyway, I'd like to know how Jingle / Jitsi does adapt to changing network conditons. The called party was on a corporate LAN with some activities taking place there while we talked, resulting in some temporary bandwith squeezes (for a couple of seconds).

Jitsi doesn't seem to adapt very well to these situations: While the images where almost as fluent as always - voice started to stutter. (the other messenger just freezes the images for a while while sound stays excelent - which is in my mind less intrusive)

Is there a way to detect network shortages on the line and adapt to e.g. by
- lowering the fps rate of the image or even suspending video for a second
- switching on the fly from the excellent G722 or Speex32000 codec to someting narrower - less Hifi but still fluent - say to GSM or ILBC (what's the point of these narrow band codecs anyway - when the almost never get used in calls Jitsi<->Jitsi)

Any ideas? Any ways to implement that?

Thank and Greetings
Conrad

... facing the challenge to get my overseas, rather networkly challenged folks to Jitsi to be able to kick out the proprietary messenger again. So it should cope whith all that imperfect, overloaded networks :wink:


#2

Hello.

I 2nd this. I've made video calls over WiFi and mobile broadband. As
the signal strength fluctuates, so does the bandwidth.

Jitsi does not handle this at all.

Currently audio constantly jitters in video calls (audio calls are
fine), which puts Jitsi at risk of being nicknamed "Jittery Jitsi" by
Skype users.

I want the voice quality to remain crystal clear, and the video
quality to decrease elegantly. By elegant, I mean reduce FPS,
resolution, colour, etc. and increase compression, avoiding the 'fuzzy
ghosting' effect caused by corrupt delta-compression.

I'm looking forward to adaptability of fluctuating bandwidth for Jitsi.

Thank you.
James.

···

On 20/04/2011, Conrad Beckert <conrad_videokonferenz@gmx.de> wrote:

Hi,

yesterday I had a nice test session with two Jitsis and then again on the
same machines and networks with another, proprietary - rather spooky but
nevertheless very popular - communication system. This has been an
interesting comparison I've never had before with any of my Open Source VoIP
systems.

Anyway, I'd like to know how Jingle / Jitsi does adapt to changing network
conditons. The called party was on a corporate LAN with some activities
taking place there while we talked, resulting in some temporary bandwith
squeezes (for a couple of seconds).

Jitsi doesn't seem to adapt very well to these situations: While the images
where almost as fluent as always - voice started to stutter. (the other
messenger just freezes the images for a while while sound stays excelent -
which is in my mind less intrusive)

Is there a way to detect network shortages on the line and adapt to e.g. by
- lowering the fps rate of the image or even suspending video for a second
- switching on the fly from the excellent G722 or Speex32000 codec to
someting narrower - less Hifi but still fluent - say to GSM or ILBC (what's
the point of these narrow band codecs anyway - when the almost never get
used in calls Jitsi<->Jitsi)

Any ideas? Any ways to implement that?

Thank and Greetings
Conrad

... facing the challenge to get my overseas, rather networkly challenged
folks to Jitsi to be able to kick out the proprietary messenger again. So it
should cope whith all that imperfect, overloaded networks :wink:


#3

Hey folks,

I pretty much agree that adapting to bandwidth changes would be quite
awesome ... and definitely non-trivial too.

Unfortunately, I am not aware of anyone in the community currently
working on this. We (BlueJimp) may implement it at some point but right
now we have our hands full with other issues so I don't expect this to
happen in the following month or two and it would then depend on funding
after that.

If, however, someone else is interested in implementing it then I'd be
happy to discuss the possibilities and work with them so that the
feature would find its way in trunk as quickly as possible.

Cheers,
Emil

На 24.04.11 13:39, James Haigh написа:

···

Hello.

I 2nd this. I've made video calls over WiFi and mobile broadband. As
the signal strength fluctuates, so does the bandwidth.

Jitsi does not handle this at all.

Currently audio constantly jitters in video calls (audio calls are
fine), which puts Jitsi at risk of being nicknamed "Jittery Jitsi" by
Skype users.

I want the voice quality to remain crystal clear, and the video
quality to decrease elegantly. By elegant, I mean reduce FPS,
resolution, colour, etc. and increase compression, avoiding the 'fuzzy
ghosting' effect caused by corrupt delta-compression.

I'm looking forward to adaptability of fluctuating bandwidth for Jitsi.

Thank you.
James.

On 20/04/2011, Conrad Beckert <conrad_videokonferenz@gmx.de> wrote:

Hi,

yesterday I had a nice test session with two Jitsis and then again on the
same machines and networks with another, proprietary - rather spooky but
nevertheless very popular - communication system. This has been an
interesting comparison I've never had before with any of my Open Source VoIP
systems.

Anyway, I'd like to know how Jingle / Jitsi does adapt to changing network
conditons. The called party was on a corporate LAN with some activities
taking place there while we talked, resulting in some temporary bandwith
squeezes (for a couple of seconds).

Jitsi doesn't seem to adapt very well to these situations: While the images
where almost as fluent as always - voice started to stutter. (the other
messenger just freezes the images for a while while sound stays excelent -
which is in my mind less intrusive)

Is there a way to detect network shortages on the line and adapt to e.g. by
- lowering the fps rate of the image or even suspending video for a second
- switching on the fly from the excellent G722 or Speex32000 codec to
someting narrower - less Hifi but still fluent - say to GSM or ILBC (what's
the point of these narrow band codecs anyway - when the almost never get
used in calls Jitsi<->Jitsi)

Any ideas? Any ways to implement that?

Thank and Greetings
Conrad

... facing the challenge to get my overseas, rather networkly challenged
folks to Jitsi to be able to kick out the proprietary messenger again. So it
should cope whith all that imperfect, overloaded networks :wink:

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31


#4

Ok. Here's an attempt to break the problem down into more manageable chunks.

* Step 1: Prioritise audio.
This is quite important and hopefully not too difficult. Maybe
prioritise in this order: 1st audio, 2nd session co-ordination data,
3rd video, 4th all non-Jitsi traffic. Would this be done with QoS?

* Step 2: Eliminate delta ghosting in video.
If an area has lost track of the delta compression, further delta data
should be discarded until the next key data. This would cause parts of
the image to freeze instead of going totally weird.

Please at least get to here before the release candidate stage. Can I
add the first 2 steps as feature requests to the issue tracker?

* Step 3: Allow to manually adjust the other persons video quality.
Ability to change the other persons resolution, colour and
compression, from within a call.

* Step 4: Implement fast video quality adaptation.
Long-term goal. Should adapt to changes in a fraction of a second.

Thank you.
James.

···

On 24/04/2011, Emil Ivov <emcho@jitsi.org> wrote:

Hey folks,

I pretty much agree that adapting to bandwidth changes would be quite
awesome ... and definitely non-trivial too.

Unfortunately, I am not aware of anyone in the community currently
working on this. We (BlueJimp) may implement it at some point but right
now we have our hands full with other issues so I don't expect this to
happen in the following month or two and it would then depend on funding
after that.

If, however, someone else is interested in implementing it then I'd be
happy to discuss the possibilities and work with them so that the
feature would find its way in trunk as quickly as possible.

Cheers,
Emil

На 24.04.11 13:39, James Haigh написа:

Hello.

I 2nd this. I've made video calls over WiFi and mobile broadband. As
the signal strength fluctuates, so does the bandwidth.

Jitsi does not handle this at all.

Currently audio constantly jitters in video calls (audio calls are
fine), which puts Jitsi at risk of being nicknamed "Jittery Jitsi" by
Skype users.

I want the voice quality to remain crystal clear, and the video
quality to decrease elegantly. By elegant, I mean reduce FPS,
resolution, colour, etc. and increase compression, avoiding the 'fuzzy
ghosting' effect caused by corrupt delta-compression.

I'm looking forward to adaptability of fluctuating bandwidth for Jitsi.

Thank you.
James.

On 20/04/2011, Conrad Beckert <conrad_videokonferenz@gmx.de> wrote:

Hi,

yesterday I had a nice test session with two Jitsis and then again on
the
same machines and networks with another, proprietary - rather spooky but
nevertheless very popular - communication system. This has been an
interesting comparison I've never had before with any of my Open Source
VoIP
systems.

Anyway, I'd like to know how Jingle / Jitsi does adapt to changing
network
conditons. The called party was on a corporate LAN with some activities
taking place there while we talked, resulting in some temporary bandwith
squeezes (for a couple of seconds).

Jitsi doesn't seem to adapt very well to these situations: While the
images
where almost as fluent as always - voice started to stutter. (the other
messenger just freezes the images for a while while sound stays excelent
-
which is in my mind less intrusive)

Is there a way to detect network shortages on the line and adapt to e.g.
by
- lowering the fps rate of the image or even suspending video for a
second
- switching on the fly from the excellent G722 or Speex32000 codec to
someting narrower - less Hifi but still fluent - say to GSM or ILBC
(what's
the point of these narrow band codecs anyway - when the almost never get
used in calls Jitsi<->Jitsi)

Any ideas? Any ways to implement that?

Thank and Greetings
Conrad

... facing the challenge to get my overseas, rather networkly challenged
folks to Jitsi to be able to kick out the proprietary messenger again. So
it
should cope whith all that imperfect, overloaded networks :wink:

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31


#5

Hey James,

На 24.04.11 23:07, James Haigh написа:

Ok. Here's an attempt to break the problem down into more manageable chunks.

* Step 1: Prioritise audio.
This is quite important and hopefully not too difficult. Maybe
prioritise in this order: 1st audio, 2nd session co-ordination data,
3rd video, 4th all non-Jitsi traffic. Would this be done with QoS?

QoS would only help in cases where the problem is related to the network
rather than Jitsi itself. Most QoS implementations would therefore be
carried out in the network itself (e.g. by using traffic shaping based
on packet content).

The problem that Conrad was describing is mostly about how video
encoding makes excessive use of CPU resources in detriment of audio
encoding and transmission. This is something that we can try to resolve
inside Jitsi but it is not a simple matter and would require both time
and experience.

* Step 2: Eliminate delta ghosting in video.
If an area has lost track of the delta compression, further delta data
should be discarded until the next key data. This would cause parts of
the image to freeze instead of going totally weird.

All this is part of H.264 encoding/decoding and we can't just modify it
at risk of becoming incompatible. Not to mention that the compression
used by H.264 is considerably more complex than simply exchanging area
deltas.

Please at least get to here before the release candidate stage. Can I
add the first 2 steps as feature requests to the issue tracker?

We'd like to start a stable line in not too long so I don't think we'll
have the audio prioritization ready by then.

Again, let me remind that the solutions that we are discussing are quite
complex while the workaround of simply asking your interlocutor to turn
off video, or doing so yourself when you detect problems is rather
simple and efficient.

* Step 3: Allow to manually adjust the other persons video quality.
Ability to change the other persons resolution, colour and
compression, from within a call.

We'll probably add the possibility for users to control their own frame
rate and resolution in the following weeks.

* Step 4: Implement fast video quality adaptation.
Long-term goal. Should adapt to changes in a fraction of a second.

Already commented on this in my previous mail.

Cheers,
Emil

···

Thank you.
James.

On 24/04/2011, Emil Ivov <emcho@jitsi.org> wrote:

Hey folks,

I pretty much agree that adapting to bandwidth changes would be quite
awesome ... and definitely non-trivial too.

Unfortunately, I am not aware of anyone in the community currently
working on this. We (BlueJimp) may implement it at some point but right
now we have our hands full with other issues so I don't expect this to
happen in the following month or two and it would then depend on funding
after that.

If, however, someone else is interested in implementing it then I'd be
happy to discuss the possibilities and work with them so that the
feature would find its way in trunk as quickly as possible.

Cheers,
Emil

На 24.04.11 13:39, James Haigh написа:

Hello.

I 2nd this. I've made video calls over WiFi and mobile broadband. As
the signal strength fluctuates, so does the bandwidth.

Jitsi does not handle this at all.

Currently audio constantly jitters in video calls (audio calls are
fine), which puts Jitsi at risk of being nicknamed "Jittery Jitsi" by
Skype users.

I want the voice quality to remain crystal clear, and the video
quality to decrease elegantly. By elegant, I mean reduce FPS,
resolution, colour, etc. and increase compression, avoiding the 'fuzzy
ghosting' effect caused by corrupt delta-compression.

I'm looking forward to adaptability of fluctuating bandwidth for Jitsi.

Thank you.
James.

On 20/04/2011, Conrad Beckert <conrad_videokonferenz@gmx.de> wrote:

Hi,

yesterday I had a nice test session with two Jitsis and then again on
the
same machines and networks with another, proprietary - rather spooky but
nevertheless very popular - communication system. This has been an
interesting comparison I've never had before with any of my Open Source
VoIP
systems.

Anyway, I'd like to know how Jingle / Jitsi does adapt to changing
network
conditons. The called party was on a corporate LAN with some activities
taking place there while we talked, resulting in some temporary bandwith
squeezes (for a couple of seconds).

Jitsi doesn't seem to adapt very well to these situations: While the
images
where almost as fluent as always - voice started to stutter. (the other
messenger just freezes the images for a while while sound stays excelent
-
which is in my mind less intrusive)

Is there a way to detect network shortages on the line and adapt to e.g.
by
- lowering the fps rate of the image or even suspending video for a
second
- switching on the fly from the excellent G722 or Speex32000 codec to
someting narrower - less Hifi but still fluent - say to GSM or ILBC
(what's
the point of these narrow band codecs anyway - when the almost never get
used in calls Jitsi<->Jitsi)

Any ideas? Any ways to implement that?

Thank and Greetings
Conrad

... facing the challenge to get my overseas, rather networkly challenged
folks to Jitsi to be able to kick out the proprietary messenger again. So
it
should cope whith all that imperfect, overloaded networks :wink:

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31


#6

We'll probably add the possibility for users to control their own frame

rate and resolution in the following weeks.<<
That is good news - as I hope that it will resolve/releave the problem with all the weaker machines I still have to work with.

Linphone can adjust the bandwith - as I remember also within a call. Unfortunately, the settings are hidden somewhere in the config.

But speaking about bandwith issues: Probably it would make sense to choose a more narrowband audio codec when bandwith becomes an issue.

Would the narrowband audio codecs ever get used in the current setup? (as I understand the negotiating process: A: "I have Speex 32k, G722, G711, GSM, ILBC" - B: "Cool, I have Speex 32k too - let's take it")

For the time beeing this is quite difficult to explain to the person at the other end to change their configs.

Is there a way for the recieving end to tell the sender that not all packets come in - or can the sender detect a jammed line? I suppose one of the RTP, SDP, XMPP, SIP protocol has some bandwith control functionality?

Anyway perhaps provisioning works for that.

Greetings, looking forward to a system, that adapts and scales better.
Conrad

PS: A slider for quality vs. bandwith would be great. It would be even better to allow the user to make the audio/video tradeoff himself (i.e. 2 sliders - the one for audio prefers narrowband codecs if in place - no problem if reestablishing the call necessary to take effect), the video one first lowers the fps rate. It should be possible to run a call as QCIF as well as sometimes a lower resolution isn't that bad of a quality as it seems like. I hope, that isn't too much complexity. Probably someone on the list has a better idea :slight_smile:

CB


#7

Hey Conrad

На 27.04.11 00:54, Conrad Beckert написа:

We'll probably add the possibility for users to control their own
frame

rate and resolution in the following weeks.<< That is good news - as
I hope that it will resolve/releave the problem with all the weaker
machines I still have to work with.

It would probably help indeed.

Linphone can adjust the bandwith - as I remember also within a call.
Unfortunately, the settings are hidden somewhere in the config.

But speaking about bandwith issues: Probably it would make sense to
choose a more narrowband audio codec when bandwith becomes an issue.

Would the narrowband audio codecs ever get used in the current setup?
(as I understand the negotiating process: A: "I have Speex 32k, G722,
G711, GSM, ILBC" - B: "Cool, I have Speex 32k too - let's take it")

Correct. Therefore, if you want to force use of a particular codec then
make sure it either appears first or simply disable all the others.

For the time beeing this is quite difficult to explain to the person
at the other end to change their configs.

Is there a way for the recieving end to tell the sender that not all
packets come in - or can the sender detect a jammed line? I suppose
one of the RTP, SDP, XMPP, SIP protocol has some bandwith control
functionality?

Yes. That happens via RTCP. The problem is that this information is not
always reliable and even when it is, one can never be sure why packets
did not arrive. It could have been because video was exceeding available
upstream bandwidth but it could have also been that bandwidth is hogged
by your torrent client or that WiFi at either end had a problem for a
second.

Besides, very often frames get bogged before they even reach the
network, when for example the encoder doesn't have enough CPU to handle
them all.

A proper adaptive policy would have to take all this into account.

Anyway perhaps provisioning works for that.

Greetings, looking forward to a system, that adapts and scales
better. Conrad

PS: A slider for quality vs. bandwith would be great. It would be
even better to allow the user to make the audio/video tradeoff
himself (i.e. 2 sliders - the one for audio prefers narrowband codecs
if in place - no problem if reestablishing the call necessary to take
effect), the video one first lowers the fps rate. It should be
possible to run a call as QCIF as well as sometimes a lower
resolution isn't that bad of a quality as it seems like. I hope, that
isn't too much complexity. Probably someone on the list has a better
idea :slight_smile:

What I suggest is that we start with the finer control that would allow
users to pick framerate, resolution and such. We can then see which are
the most popular and helpful ones and maybe export some, or a
combination of them in simplified presets like the sliders you are
proposing.

Cheers,
Emil


#8

...

upstream bandwidth but it could have also been that bandwidth is hogged
by your torrent client...

This would be solved by QoS. Jitsi can't do anything about this and it
has to be implemented by the router, right?

...

What I suggest is that we start with the finer control that would allow
users to pick framerate, resolution and such. We can then see which are
the most popular and helpful ones and maybe export some, or a
combination of them in simplified presets like the sliders you are
proposing.

It should be the receiver that chooses the settings of the sender.
People will have different preferences. I would prefer a higher res
image with low compression (I /hate/ *PEG compression artifacts!), at
the expense of grey-scale colour and low FPS. Someone else may prefer
high colour and FPS at the expense of resolution and compression. It's
only the receiver who cares about these settings, and if the sender
had control over this, the receiver will constantly be asking the
sender to adjust a setting.

Note that in this case, there is no need for the sender to detect
packet loss. The receiver notices a problem with the quality and
adjusts the controls. Simple! XMPP messages are sent back to the
sender which adjusts the quality accordingly.

James.

···

On 27/04/2011, Emil Ivov <emcho@jitsi.org> wrote:


#9

Hi James, everyone,

I've been watching this thread unfold and am quite pleased with the
ideas. Some of the outcome is simple and robust : the slider thing
that adjusts the set of codecs and so on sounds like a good thing to
have, provided that it can be calibrated easily.

Remember that different people (industry, home user, academic) have
different parameters and expectations. Same goes for countries : even
if you managed to get some information like "this interface is 3G" you
should see the difference of 3G service between TokyoJP and
StrasbourgFR, it is quite surprising.

upstream bandwidth but it could have also been that bandwidth is hogged
by your torrent client...

This would be solved by QoS. Jitsi can't do anything about this and it
has to be implemented by the router, right?

True jitsi can't do anything about unfair clients. Nor can QoS, there
is no real way to make sure that your
room-mate/husband/wife/neighbor/wifisquatter plays fair. The only
proven way to achieve QoS that I know of, is called
over-provisionning. It is very efficient and it scales well, as I
could witness during the terrible incidents here in Japan. As long as
the fibers were not severed, voip was rolling and beating cellphones
single handed (sic).

I understand you were talking about QoS on the local side, but it does
not really solve the problem especially if wifi is involved.

It should be the receiver that chooses the settings of the sender.

I see a few good reasons that I would not want a receiver to change my
sending settings. One of them is 'none of your business' ;-).

But anyway, it is very difficult to assert the state of the system
locally in a OS-independent and network agnostic way (bandwidth
available [all the way to the peer], cpu load, etc...) so it is an
order of magnitude harder to figure this out remotely.

I agree that you might have your receiving preferences, so do I, they
should be mapped to the magic slider in the best possible way.
Probably you can't tradeoff framerate for frame quality and so on, but
it stays very simple.

Note that in this case, there is no need for the sender to detect
packet loss. The receiver notices a problem with the quality and
adjusts the controls. Simple! XMPP messages are sent back to the
sender which adjusts the quality accordingly.

Of course it sounds simple. Now imagine you're sitting across the
street of your favorite hotspot and here comes the bus (Emil's
example). I actually clearly remember this happening to me and what
should happen ? All adaptive processes have
hysteresis/thresholds/ping-pong problems and the moment you decide on
threshold values, you start having those false positives and the
system is just globally useless.

My point of view is that given the complexity of the system, we should
not put too much effort in it, if these problems do not impact a
significant part of the users. Now if jitsi if currently not useable
for you in this situation, we should investigate indeed.

What do you think ?

Cheers,
Jean


#10

...

It should be the receiver that chooses the settings of the sender.

I see a few good reasons that I would not want a receiver to change my
sending settings. One of them is 'none of your business' ;-).

But anyway, it is very difficult to assert the state of the system
locally in a OS-independent and network agnostic way (bandwidth
available [all the way to the peer], cpu load, etc...) so it is an
order of magnitude harder to figure this out remotely.

The sending client gives a list of available resolutions, colours,
frame rates, and compression levels via XMPP. The receiving client
presents this to the user as quality controls, and sends the users
choice back over XMPP.

...

Note that in this case, there is no need for the sender to detect
packet loss. The receiver notices a problem with the quality and
adjusts the controls. Simple! XMPP messages are sent back to the
sender which adjusts the quality accordingly.

Just to clarify, there is nothing automatic here. It is the /user/ of
the receiving client who manually notices the quality degrade. They
can then manually adjust the quality controls.

This really would be simple to implement as there is no automatic
detection of bad quality.

James.

···

On 02/05/2011, Jean Lorchat <jean.lorchat@gmail.com> wrote:

Of course it sounds simple. Now imagine you're sitting across the
street of your favorite hotspot and here comes the bus (Emil's
example). I actually clearly remember this happening to me and what
should happen ? All adaptive processes have
hysteresis/thresholds/ping-pong problems and the moment you decide on
threshold values, you start having those false positives and the
system is just globally useless.

My point of view is that given the complexity of the system, we should
not put too much effort in it, if these problems do not impact a
significant part of the users. Now if jitsi if currently not useable
for you in this situation, we should investigate indeed.

What do you think ?

Cheers,
Jean


#11

This really would be simple to implement

Excellent! Looking forward to your patch then!

I'd love to contribute code to Jitsi if I knew Java. For the time
being, I'm contributing to an open source project written in Python.

Surely this idea is simpler to implement than automatic detection, right?

James.

···

On 02/05/2011, Emil Ivov <emcho@jitsi.org> wrote:

On 2 mai 2011, at 19:39, James Haigh <james.r.haigh@gmail.com> wrote:

Cheers,
Emil

--sent from my mobile


#12

На 02.05.11 20:21, James Haigh написа:

This really would be simple to implement

Excellent! Looking forward to your patch then!

I'd love to contribute code to Jitsi if I knew Java. For the time
being, I'm contributing to an open source project written in Python.

Surely this idea is simpler to implement than automatic detection, right?

I believe I've already commented on this:

1. We (the BlueJimp dev team) are currently implementing the possibility
for users to control their framerate resolution and maximum allowed
bandwidth.

2. At some point in the future we may also try to add some way to
automatically drop framerate (or resolution) in case we detect that the
machine isn't coping with the current settings.

3. Slider-like presets are also a possibility.

4. We don't currently have plans for autoadaptive streaming.

(I just made sure these are reflected on the roadmap)

Again, this only concerns our plans at BlueJimp. We would gladly take
patches from anyone on 2, and 3. We would not refuse 4 either but I'd
like it to be backed up by sound reasoning and experimentation as the
false negatives that Jean mentioned are something that we are also
worried about. Not to mention that the complexity of such an
implementation would be hard to justify by the gains.

Hope this makes it clearer.

Emil

···

On 02/05/2011, Emil Ivov <emcho@jitsi.org> wrote:

On 2 mai 2011, at 19:39, James Haigh <james.r.haigh@gmail.com> wrote:


#13

...

1. We (the BlueJimp dev team) are currently implementing the possibility
for users to control their framerate resolution and maximum allowed
bandwidth.

This would be great if it would control the /other/ person's frame
rate and resolution instead of your own. It makes far more sense if
the controls affect what /you/ see rather than what the other person
sees. It's not very intuitive to have controls that you can't see what
effect they've had unless the other person describes it to you.

I'm not sure that I've been fully understood. There is nothing
automatic about this, it's just swapping the controls round.

I've lost interest in the automatic stuff below because of the
difficulty in implementation. The ability to control the quality of
the received video will be a much better solution that is achievable.
Internet connections and CPUs are becoming faster all the time anyway,
so it may not be worth implementing auto-adaptation at all.

James.

···

On 02/05/2011, Emil Ivov <emcho@jitsi.org> wrote:

2. At some point in the future we may also try to add some way to
automatically drop framerate (or resolution) in case we detect that the
machine isn't coping with the current settings.

3. Slider-like presets are also a possibility.

4. We don't currently have plans for autoadaptive streaming.

(I just made sure these are reflected on the roadmap)

Again, this only concerns our plans at BlueJimp. We would gladly take
patches from anyone on 2, and 3. We would not refuse 4 either but I'd
like it to be backed up by sound reasoning and experimentation as the
false negatives that Jean mentioned are something that we are also
worried about. Not to mention that the complexity of such an
implementation would be hard to justify by the gains.

Hope this makes it clearer.

Emil


#14

James, while I'm not strictly against the remote party having control
over what they receive, I think it should be limited to the preference
of the local party at best. For example, if I specify that I want to
send a specific size/resolution, frame rate, etc., the remote party
shouldn't be able to make me send a larger size/resolution, frame
rate, etc. because I might have chosen my settings so that they don't
exceed a certain bandwidth.

···

On Tue, May 3, 2011 at 12:55 AM, James Haigh <james.r.haigh@gmail.com> wrote:

This would be great if it would control the /other/ person's frame
rate and resolution instead of your own. It makes far more sense if
the controls affect what /you/ see rather than what the other person
sees. It's not very intuitive to have controls that you can't see what
effect they've had unless the other person describes it to you.


#15

Adding to what Lubo said

На 03.05.11 00:55, James Haigh написа:

...

1. We (the BlueJimp dev team) are currently implementing the possibility
for users to control their framerate resolution and maximum allowed
bandwidth.

This would be great if it would control the /other/ person's frame
rate and resolution instead of your own.

With my lead hat on:

I don't think this is currently on anyone's todo list. If someone is
interested in developing that, I'd be happy to discuss with them the
best way to go forward.

As an individual:

I think this idea would hardly be any improvement for the majority of
the users. It takes away complexity from one of the parties only to dump
it on the other one. I don't see where the difference is from, say,
opening a desktop sharing session and configuring the other person's
settings or simply explaining what they should do.

Also note that we already indicate the maximum resolution that we are
able to display so that the remote party does not send more than that.

Cheers,
Emil

···

On 02/05/2011, Emil Ivov <emcho@jitsi.org> wrote:

2. At some point in the future we may also try to add some way to
automatically drop framerate (or resolution) in case we detect that the
machine isn't coping with the current settings.

3. Slider-like presets are also a possibility.

4. We don't currently have plans for autoadaptive streaming.

(I just made sure these are reflected on the roadmap)

Again, this only concerns our plans at BlueJimp. We would gladly take
patches from anyone on 2, and 3. We would not refuse 4 either but I'd
like it to be backed up by sound reasoning and experimentation as the
false negatives that Jean mentioned are something that we are also
worried about. Not to mention that the complexity of such an
implementation would be hard to justify by the gains.

Hope this makes it clearer.

Emil

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31


#16

...

With my lead hat on:

I don't think this is currently on anyone's todo list. If someone is
interested in developing that, I'd be happy to discuss with them the
best way to go forward.

Well, it seems that this "someone" might be us (BlueJimp) after all.
After a completely unrelated discussion with one of our customers, it
turned out that they needed something similar which in turn means that
we'd be able to allocate resources and do some work on this issue.

Funny how things work out sometimes ...

Well that's good news! :smiley:

This would be great if it would control the /other/ person's frame
rate and resolution instead of your own. It makes far more sense if
the controls affect what /you/ see rather than what the other person
sees. It's not very intuitive to have controls that you can't see what
effect they've had unless the other person describes it to you.

James, while I'm not strictly against the remote party having control
over what they receive, I think it should be limited to the preference
of the local party at best. For example, if I specify that I want to
send a specific size/resolution, frame rate, etc., the remote party
shouldn't be able to make me send a larger size/resolution, frame
rate, etc. because I might have chosen my settings so that they don't
exceed a certain bandwidth.

Yes, there's a solution to that. I'd only interested in the actual
bandwidth used, rather than whether they prefer a good frame rate or
resolution etc. So I set a maximum bandwidth and they choose how they
use that.

I'm sorry that I can be of no help with the Java coding at this point
in my life, but this is how I imagine the basic process will work:

* The remote client gives a list of available resolutions, colour
modes, frame rates, compression levels, and audio codecs via XMPP,
along with the maximum 'upload' bandwidth set by the user.

* The local client presents this to the user as quality controls.
They only allow combinations that are within the max bandwidth.

* The local client sends the users choice back over XMPP.

* The remote client changes the sent quality. If it is a conference
call, it should take the minimum requested of each setting.

I hope this at least helps with the planning stage if only a little.

James.

···

On 03/05/2011, Emil Ivov <emcho@jitsi.org> wrote:
On 03/05/2011, Lyubomir Marinov <lubo@jitsi.org> wrote:

On Tue, May 3, 2011 at 12:55 AM, James Haigh <james.r.haigh@gmail.com> > wrote:


#17

На 03.05.11 11:00, Emil Ivov написа:

Adding to what Lubo said

На 03.05.11 00:55, James Haigh написа:

...

1. We (the BlueJimp dev team) are currently implementing the possibility
for users to control their framerate resolution and maximum allowed
bandwidth.

This would be great if it would control the /other/ person's frame
rate and resolution instead of your own.

With my lead hat on:

I don't think this is currently on anyone's todo list. If someone is
interested in developing that, I'd be happy to discuss with them the
best way to go forward.

Well, it seems that this "someone" might be us (BlueJimp) after all.
After a completely unrelated discussion with one of our customers, it
turned out that they needed something similar which in turn means that
we'd be able to allocate resources and do some work on this issue.

Funny how things work out sometimes ...

···

On 02/05/2011, Emil Ivov <emcho@jitsi.org> wrote: