[jitsi-dev] Change Video Settings


#1

Hi,

... it's very nice to see that feature - I asked before, so I couldn't miss the first oportunity to give it a test. This is what's going on:

Setup: Two latest Jitsis 3470 on a LAN, these two cameras:
Bus 001 Device 002: ID 0ac8:3420 Z-Star Microelectronics Corp. Venus USB2.0 Camera
and on the other side
Bus 001 Device 002: ID 064e:a101 Suyin Corp. Acer CrystalEye Webcam

Results:
1. It's not possible to set a different resolution - they stay the same for all options in the list, no matter if lower or higher. Changing this setting does not affect the amount of data transfered either.
2. The Max Bandwidth Setting seem to have an effect - but only by creating artefacts or even large image latency. (what a narrowband net does anyway)
3. Changing the framerate has no observable effect - not in the image nor in the bandwidth measured.

What's wrong?

- What is the objective of these settings? a) take effect in the next call b) take effect after switching video off and on again c) take effect immediately
- Is the resolution linked to the camera or does Jitsy scale the image from the camera on the fly? How would I know if the camera doesn't support a selected resolution?
- Does "Max Bandwidth" set the video encoding bitrate?

Thanks for implementing nice features :slight_smile: I hope to get hold on an Atom netbook soon to test whether Jitsi works there with smaller resolutions.

Greetings
Conrad

PS: As this settings are to be changed more often than e.g. the video codecs - it might have deserved a more prominent place in the settings window doesn't it.


#2

Hi,

thanks for testing and sharing the results. Those settings are not
supposed to work on the fly durring a call. So you make the change in
settings and then start the call.

Hi,

... it's very nice to see that feature - I asked before, so I couldn't miss
the first oportunity to give it a test. This is what's going on:

Setup: Two latest Jitsis 3470 on a LAN, these two cameras:
Bus 001 Device 002: ID 0ac8:3420 Z-Star Microelectronics Corp. Venus USB2.0
Camera
and on the other side
Bus 001 Device 002: ID 064e:a101 Suyin Corp. Acer CrystalEye Webcam

Results:
1. It's not possible to set a different resolution - they stay the same for
all options in the list, no matter if lower or higher. Changing this setting
does not affect the amount of data transfered either.

Can you try with build.3477, there was some bug when v4l datasource
choose the video size. My camera drivers seem that doesn't support all
the resolutions and so it sticks to the closest resolution, for
example 320/240 and 352/288 both produces video with size 320/240.

2. The Max Bandwidth Setting seem to have an effect - but only by creating
artefacts or even large image latency. (what a narrowband net does anyway)

3. Changing the framerate has no observable effect - not in the image nor in
the bandwidth measured.

On my side there is some changes when you put the frame rate lower than 15.

What's wrong?

- What is the objective of these settings? a) take effect in the next call
b) take effect after switching video off and on again c) take effect
immediately
- Is the resolution linked to the camera or does Jitsy scale the image from
the camera on the fly? How would I know if the camera doesn't support a
selected resolution?
- Does "Max Bandwidth" set the video encoding bitrate?

No its not, it just limits the bandwidth which the network part produces.

Regards
damencho

···

On Fri, May 13, 2011 at 10:37 PM, Conrad Beckert <conrad_videokonferenz@gmx.de> wrote:


#3

Hi Damian,

now it seems to work better. I'm able to resize the image when reestablishing the call.

It is still hard to keep the image from disintegrating when there is a lot of movement in it. Lowering the frame rate doesn't seem to have an effect.

The bandwith setting defaults to 100 - but I'm not so shure if it is kbit/s or kbyte/s. The latter one is in the UI, the first one is the unit bandwidth is usually measured.

If the label is correct - then the setting is 800 kbit/s- too much for my DSL line and hence a good candidate for the failure. The settings might not have been that high before when it was hardcoded?!. BTW What where the values then?

What is the desired effect of lowering the bandwidh setting? A consistent image for the price of less resolution by increasing compression?

Thanks for the answers - Jitsi is getting better each day - its fun to test :wink:

Greetings
Conrad

-------- Original-Nachricht --------

···

Datum: Wed, 18 May 2011 17:40:23 +0300
Von: Damian Minkov <damencho@jitsi.org>
An: dev@jitsi.java.net
Betreff: [jitsi-dev] Re: Change Video Settings

Hi,

thanks for testing and sharing the results. Those settings are not
supposed to work on the fly durring a call. So you make the change in
settings and then start the call.

On Fri, May 13, 2011 at 10:37 PM, Conrad Beckert > <conrad_videokonferenz@gmx.de> wrote:
> Hi,
>
> ... it's very nice to see that feature - I asked before, so I couldn't
miss
> the first oportunity to give it a test. This is what's going on:
>
> Setup: Two latest Jitsis 3470 on a LAN, these two cameras:
> Bus 001 Device 002: ID 0ac8:3420 Z-Star Microelectronics Corp. Venus
USB2.0
> Camera
> and on the other side
> Bus 001 Device 002: ID 064e:a101 Suyin Corp. Acer CrystalEye Webcam
>
>
> Results:
> 1. It's not possible to set a different resolution - they stay the same
for
> all options in the list, no matter if lower or higher. Changing this
setting
> does not affect the amount of data transfered either.
Can you try with build.3477, there was some bug when v4l datasource
choose the video size. My camera drivers seem that doesn't support all
the resolutions and so it sticks to the closest resolution, for
example 320/240 and 352/288 both produces video with size 320/240.

> 2. The Max Bandwidth Setting seem to have an effect - but only by
creating
> artefacts or even large image latency. (what a narrowband net does
anyway)

> 3. Changing the framerate has no observable effect - not in the image
nor in
> the bandwidth measured.
On my side there is some changes when you put the frame rate lower than
15.

>
> What's wrong?
>
> - What is the objective of these settings? a) take effect in the next
call
> b) take effect after switching video off and on again c) take effect
> immediately
> - Is the resolution linked to the camera or does Jitsy scale the image
from
> the camera on the fly? How would I know if the camera doesn't support a
> selected resolution?
> - Does "Max Bandwidth" set the video encoding bitrate?
No its not, it just limits the bandwidth which the network part produces.

Regards
damencho


#4

Hello,

I use Jitsi on Debian Testing (kernel 2.6.38-bigmem) and i noticed that in recent builds my webcam does not work anymore (it was working before). Now i get a light gray square instead of the camera image.

The webcam is:

0ac8:305b Z-Star Microelectronics Corp. ZC0305 Webcam

Uses the gspca driver. It was working before well. In certain apps (Skype, Pidgin) i have to preload the /usr/lib/libv4l/v4l1compat.so library to make it work, but i did not need that for Jitsi.

I spotted some errors in the logs:

java.lang.RuntimeException: Could not open codec CODEC_ID_MJPEG
  at net.java.sip.communicator.impl.neomedia.jmfext.media.protocol.video4linux2.Video4Linux2Stream.doRead(Video4Linux2Stream.java:267)
  at net.java.sip.communicator.impl.neomedia.jmfext.media.protocol.AbstractVideoPullBufferStream.read(AbstractVideoPullBufferStream.java:145)
  at com.sun.media.parser.RawPullBufferParser$FrameTrack.readFrame(RawPullBufferParser.java:126)
  at com.sun.media.SourceThread.process(SourceThread.java:83)
  at com.sun.media.util.LoopThread.run(LoopThread.java:135)

Output of v4l-info:

$ v4l-info

### v4l2 device info [/dev/video0] ###
general info
    VIDIOC_QUERYCAP
  driver : "zc3xx"
  card : "PC Camera"
  bus_info : "usb-0000:00:02.0-5"
  version : 2.12.0
  capabilities : 0x5000001 [VIDEO_CAPTURE,READWRITE,STREAMING]

standards

inputs
    VIDIOC_ENUMINPUT(0)
  index : 0
  name : "zc3xx"
  type : CAMERA
  audioset : 0
  tuner : 0
  std : 0x0 []
  status : 0x0 []

video capture
    VIDIOC_ENUM_FMT(0,VIDEO_CAPTURE)
  index : 0
  type : VIDEO_CAPTURE
  flags : 1
  description : "JPEG"
  pixelformat : 0x4745504a [JPEG]
    VIDIOC_G_FMT(VIDEO_CAPTURE)
  type : VIDEO_CAPTURE
  fmt.pix.width : 640
  fmt.pix.height : 480
  fmt.pix.pixelformat : 0x4745504a [JPEG]
  fmt.pix.field : NONE
  fmt.pix.bytesperline : 640
  fmt.pix.sizeimage : 115790
  fmt.pix.colorspace : JPEG
  fmt.pix.priv : 0

controls
    VIDIOC_QUERYCTRL(BASE+0)
  id : 9963776
  type : INTEGER
  name : "Brightness"
  minimum : 0
  maximum : 255
  step : 1
  default_value : 128
  flags : 0
    VIDIOC_QUERYCTRL(BASE+1)
  id : 9963777
  type : INTEGER
  name : "Contrast"
  minimum : 0
  maximum : 255
  step : 1
  default_value : 128
  flags : 0

Please look into this issue.

···

--
O zi buna,

Kertesz Laszlo


#5

Hey Conrad,

На 18.05.11 22:59, Conrad Beckert написа:

Hi Damian,

now it seems to work better. I'm able to resize the image when
reestablishing the call.

It is still hard to keep the image from disintegrating when there is
a lot of movement in it. Lowering the frame rate doesn't seem to have
an effect.

The bandwith setting defaults to 100 - but I'm not so shure if it is
kbit/s or kbyte/s. The latter one is in the UI, the first one is the
unit bandwidth is usually measured.

If the label is correct

It is.

- then the setting is 800 kbit/s- too much
for my DSL line and hence a good candidate for the failure. The
settings might not have been that high before when it was
hardcoded?!.

BTW What where the values then?

Same as the current defaults.

What is the desired effect of lowering the bandwidh setting? A
consistent image for the price of less resolution by increasing
compression?

The "max bandwidth" setting has no effect on encoding. It only concerns
the RTP stack. The feature is supposed to help during traffic bursts
that happen, for example when sending key frames. It works by keeping
packets in a queue and making sure that we don't send more than the cap.
As a result the picture that the remote party sees may stall a little or
feel a bit jumpy at times, but it would show less artefacts that come
with packet loss.

Cheers,
Emil

···

Thanks for the answers - Jitsi is getting better each day - its fun
to test :wink:

Greetings Conrad

-------- Original-Nachricht --------

Datum: Wed, 18 May 2011 17:40:23 +0300 Von: Damian Minkov
<damencho@jitsi.org> An: dev@jitsi.java.net Betreff: [jitsi-dev]
Re: Change Video Settings

Hi,

thanks for testing and sharing the results. Those settings are not
supposed to work on the fly durring a call. So you make the change
in settings and then start the call.

On Fri, May 13, 2011 at 10:37 PM, Conrad Beckert >> <conrad_videokonferenz@gmx.de> wrote:

Hi,

... it's very nice to see that feature - I asked before, so I
couldn't

miss

the first oportunity to give it a test. This is what's going on:

Setup: Two latest Jitsis 3470 on a LAN, these two cameras: Bus
001 Device 002: ID 0ac8:3420 Z-Star Microelectronics Corp. Venus

USB2.0

Camera and on the other side Bus 001 Device 002: ID 064e:a101
Suyin Corp. Acer CrystalEye Webcam

Results: 1. It's not possible to set a different resolution -
they stay the same

for

all options in the list, no matter if lower or higher. Changing
this

setting

does not affect the amount of data transfered either.

Can you try with build.3477, there was some bug when v4l
datasource choose the video size. My camera drivers seem that
doesn't support all the resolutions and so it sticks to the closest
resolution, for example 320/240 and 352/288 both produces video
with size 320/240.

2. The Max Bandwidth Setting seem to have an effect - but only
by

creating

artefacts or even large image latency. (what a narrowband net
does

anyway)

3. Changing the framerate has no observable effect - not in the
image

nor in

the bandwidth measured.

On my side there is some changes when you put the frame rate lower
than 15.

What's wrong?

- What is the objective of these settings? a) take effect in the
next

call

b) take effect after switching video off and on again c) take
effect immediately - Is the resolution linked to the camera or
does Jitsy scale the image

from

the camera on the fly? How would I know if the camera doesn't
support a selected resolution? - Does "Max Bandwidth" set the
video encoding bitrate?

No its not, it just limits the bandwidth which the network part
produces.

Regards damencho

--
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

I'm sorry, I've unintentionally rebuilt the FFmpeg library on Linux
without mjpeg. I'll try to correct it soon.

···

On Thu, May 19, 2011 at 12:27 AM, Kertesz Laszlo <laszlo.kertesz@gmail.com> wrote:

java.lang.RuntimeException: Could not open codec CODEC_ID_MJPEG


#7

Thank You.

···

On Thu, 19 May 2011 09:57:34 +0300 Lyubomir Marinov <lubo@jitsi.org> wrote:

On Thu, May 19, 2011 at 12:27 AM, Kertesz Laszlo > <laszlo.kertesz@gmail.com> wrote:
> java.lang.RuntimeException: Could not open codec CODEC_ID_MJPEG

I'm sorry, I've unintentionally rebuilt the FFmpeg library on Linux
without mjpeg. I'll try to correct it soon.

--
O zi buna,

Kertesz Laszlo


#8

Hi,

I see that Google talk received some attention lately - now it works between Jitsi and Pidgin (at least). To be able to call Pidgin the "use ICE" checkbox has to be unchecked.

But it des not work with the Gmail webplugin (and probably not with the Windows Google talk client) - i think it was working a few builds back though.

Will it work?

PS. Jitsi voice and video seems to work stable with Jabber and Google Talk accounts now, including screen sharing. Good work.

···

--
O zi buna,

Kertesz Laszlo


#9

Hi,

Le 19/05/11 09:24, Kertesz Laszlo a �crit :

Hi,

I see that Google talk received some attention lately - now it works between Jitsi and Pidgin (at least). To be able to call Pidgin the "use ICE" checkbox has to be unchecked.

But it des not work with the Gmail webplugin (and probably not with the Windows Google talk client) - i think it was working a few builds back though.

Gmail webplugin and Google Talk client use a very old version of Jingle and ICE which are incompatible with the recent Jingle specification and ICE RFC we support.

But we are currently working on supporting Google Talk Jingle and ICE dialect.

Will it work?

PS. Jitsi voice and video seems to work stable with Jabber and Google Talk accounts now, including screen sharing. Good work.

Thank you ;).

Regards,

···

--
Seb


#10

Adding to what Seb said:

На 19.05.11 09:30, Sebastien Vincent написа:

Hi,

Hi,

I see that Google talk received some attention lately - now it
works between Jitsi and Pidgin (at least). To be able to call
Pidgin the "use ICE" checkbox has to be unchecked.

If you don't use ICE, you would only be able to connect if your XMPP
server can do latching or if your peers are in the same LAN as you, or
have public IPv4 or IPv6 addresses.

But it des not work with the Gmail webplugin (and probably not with
the Windows Google talk client) - i think it was working a few
builds back though.

Unless Google silently enabled support for standard Jingle and ICE and
then disabled it again, it is unlikely that voice and video between
Jitsi and GTalk/Gmail have ever worked.

They soon will though :wink:

Emil

···

Le 19/05/11 09:24, Kertesz Laszlo a écrit :

Gmail webplugin and Google Talk client use a very old version of
Jingle and ICE which are incompatible with the recent Jingle
specification and ICE RFC we support.

But we are currently working on supporting Google Talk Jingle and ICE
dialect.

Will it work?

PS. Jitsi voice and video seems to work stable with Jabber and
Google Talk accounts now, including screen sharing. Good work.

Thank you ;).

Regards, -- Seb


#11

I've rebuilt the FFmpeg JNI library on Linux to include the MJPEG
decoder and parser and committed it in r8614. Could you please test it
and let me know if the problem persists?

···

<laszlo.kertesz@gmail.com> wrote:
> java.lang.RuntimeException: Could not open codec CODEC_ID_MJPEG


#12

It works now. Thank you.

···

On Thu, 19 May 2011 20:20:15 +0300 Lyubomir Marinov <lubo@jitsi.org> wrote:

>> <laszlo.kertesz@gmail.com> wrote:
>> > java.lang.RuntimeException: Could not open codec CODEC_ID_MJPEG

I've rebuilt the FFmpeg JNI library on Linux to include the MJPEG
decoder and parser and committed it in r8614. Could you please test it
and let me know if the problem persists?

--
O zi buna,

Kertesz Laszlo