Desktop Sharing Linux One Way Only

[BoBeR182]

I am running Arch linux and using the AUR for jitsi [0]

I can receive a shared desktop from a Windows user, and if they allow remote control I can control it.

If I share my desktop, fixed region or full-screen, they do not see anything or are able to control anything.

What would help debug this?

[0] https://aur.archlinux.org/packages/jitsi/

[ibauersachs]

Reading the bug reporting guidelines would be a start. They tell you to write to the mailing list and send the logs.

[BoBeR182]

Thank you for the direction, I am slightly confused.
It lists to send my bug to the dev list here [0], and to send my bug to the users list here [1].

[0] https://jitsi.org/Documentation/ReportingBugs
[1] https://jitsi.org/Development/BugsAndIssues

[GNUDimarik]

Did anyone try to reproduce it under Ubuntu?

[GNUDimarik]

@ibauersachs I going to check this issue soon. Just in case: please let me know where I can get source code of libjnffmpeg, libjnvideo4linux2 and other libj libraries?
May be I'll have some time in future for porting the libraries to the latest ffmpeg and update other libraries.

[damencho]

@GNUDimarik libjnffmpeg is from here: https://github.com/jitsi/jitsi-lgpl-dependencies
The rest are from here: https://github.com/jitsi/libjitsi

[GNUDimarik]

@damencho thanks!

[GNUDimarik]

@damencho please let me know:
libjnffmpeg.so
libjnffmpeg-ffmpeg.so
What's difference?

When I built native libraries it built 2 libffmpeg.so with and without h264 support.
When I built new ones with statically built ffmpeg with h264 support it started to work. The both: camera and screen sharing. I think it was because I had irrelevant libav* libraries and static likning should help us to avoid it.
Is that right way? If so
will do the same for linux 32 bit and make pull request to https://github.com/jitsi/jitsi-lgpl-dependencies

[GNUDimarik]

Here is dependencies list:
ldd jnffmpeg_oh264/libjnffmpeg_oh264.so
linux-vdso.so.1 => (0x00007fffa71a2000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f9d44e52000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9d44a89000)
/lib64/ld-linux-x86-64.so.2 (0x00007f9d4553a000)
I think it's good enough for making it more portability. I'm sure this library should work on most linux distors but of course I tested it locally only.
@BoBeR182 can you help with testing?

[damencho]

No, we deliberately didn't link the libraries and use dynamic linking. This way it is used whatever is on the system, and it will be using x264, which we do not want to ship and this for Linux, while on windows and mac it will be using openh264.

The -ffmpeg libraries are for Ubuntu/Debian differences in naming the libraries, I don't know them by heart, but you can go and check latest two stable/LTS releases of Debian/Ubuntu and you will see the difference in naming the libraries.

You can also see those naming stuff and in the control file:

Depends: default-jre | java7-runtime,
 libavformat57 | libavformat-ffmpeg56,
 libavcodec57 | libavcodec-extra57 | libavcodec-ffmpeg56 | libavcodec-ffmpeg-extra56,
 libavfilter6 | libavfilter-extra6 | libavfilter-ffmpeg5,
 libavutil55 | libavutil-ffmpeg54,
 libswscale4 | libswscale-ffmpeg3,

So those ffmpeg binaries have difference dynamic links and are built on the corresponding debian/ubuntu x86/x64...

Why do you need to rebuild the binaries?

[GNUDimarik]

I saw that depencencies. Let me upgrade the distro and check once more

[damencho]

Why do you need to rebuild those binaries, is it only for local testing or?

[GNUDimarik]

App shown me exceptions about depenencies which can't be installed without system ugrade (after I'll let you know). I decided to build it statically and check. Also I think those deps making jitsi unusable under older linux distros when user has irrelevant libraries like me.
It started to work with one little issue: camera preview fails with EINVAL from libavgraph.

[damencho]

Well, I'm not sure that we cleared the exceptions, but about ffmpeg you can see that there are few library loads one after another, the logic is supposing some of the binaries to fail till one succeeds are you sure that nothing loaded at the end...
The binaries and version for different os and versions, we choose that we cover two stable releases for Debian and two LTS releases for Ubuntu, both cover more than two years so ...

[GNUDimarik]

After system update the same behaviour like with static binaries but without them. So it works fine under Ubuntu 18.04

[ibauersachs]

@damencho So much time has passed now and I wonder if we should drop support for Ubuntu 16.04 (well, at least if for ffmpeg/h264). It would make things so much easier...

[marclaporte]

Easier is good. +1 to only support current LTS of Ubuntu Desktop

[damencho]

We can do that, I don't insist on sticking to 16.04, especially when it will be easier :) so we will have more time for other stuff.

[marclaporte]

As @GNUDimarik reports that it "works fine under Ubuntu 18.04", I propose we close this. @BoBeR182: Please re-open if it doesn't work for you in Ubuntu 18.04.