flathub / net.jami.Jami

https://flathub.org/apps/details/net.jami.Jami
GNU General Public License v3.0
7 stars 7 forks source link

[WIP][Help if you want]flatpak: fix issues with current flatpak #8

Closed AmarOk1412 closed 4 years ago

AmarOk1412 commented 4 years ago

NOTE: THIS IS STILL A DIRTY WIP

TODOS:

Fixes #6 #4

flathubbot commented 4 years ago

Started test build 9240

flathubbot commented 4 years ago

Build 9240 failed

ntninja commented 4 years ago

Sorry for not getting in touch with you sooner about this! I'm currently trying (yet again) to get the current version of Jami to compile on Flathub – hopefully this PR ends up providing some insights into how to do that.

As for the PR itself: Sorry to say this, but this absolutely unmergable. You disabled several useful features (systray, address book access) and disabled build confinement (network access during builds is strictly forbidden), so I'll only use this as a rough guide for some things.

AmarOk1412 commented 4 years ago

Sorry for not getting in touch with you sooner about this! I'm currently trying (yet again) to get the current version of Jami to compile on Flathub – hopefully this PR ends up providing some insights into how to do that.

As for the PR itself: Sorry to say this, but this absolutely unmergable. You disabled several useful features (systray, address book access) and disabled build confinement (network access during builds is strictly forbidden), so I'll only use this as a rough guide for some things.

Yeah I don't want to merge that issue, it's just a big WIP and debug for me to know what is missing. The big problem for now is that udev seems to not work in flatpak, because camera are not discovered and this breaks the main feature.

I don't have enough time to try to package for more platforms for now.

ntninja commented 4 years ago

No problem, this was already quite helpful nonetheless.

Some questions about the stuff you did though:

AmarOk1412 commented 4 years ago

It's even worse. If you want to debug, you can open the dring binary in the flatpak with -cd option to get logs. I did it to see. the daemon is not detecting camera (the code about that uses udev).

EDS is not supported since 2 years in the gnome client.

And yeah if I remember (I did it month ago), but current flatpak doesn't import dring, only the client, so the binary can't work. Jami needs client+daemon (working via dbus). That's the reason of the dbus-cpp thing.

ntninja commented 4 years ago

It's even worse. If you want to debug, you can open the dring binary in the flatpak with -cd option to get logs. I did it to see. the daemon is not detecting camera (the code about that uses udev).

Thanks for the tip, I may check it out.

EDS is not supported since 2 years in the gnome client.

That's good to know as well. I'll drop that build step then.

And yeah if I remember (I did it month ago), but current flatpak doesn't import dring, only the client, so the binary can't work. Jami needs client+daemon (working via dbus). That's the reason of the dbus-cpp thing.

No, dring is part of the current flatpak, but it will assert a few seconds after startup. [It's also automatically started (via dbus service activation) from the Flatpak, so no need for that start script.] Fortunately, no more assertions with the current version, so the application is actually useful now.

ntninja commented 4 years ago

Another question:

When you said:

Build ffmpeg in contrib to allow all codecs + hardware acceleration

which codecs did you have in mind specifically? Is this list of extra codecs sufficient for your needs? (No need to rebuild ffmpeg in this case, just depending on the runtime extension 'd be sufficient.)

AmarOk1412 commented 4 years ago

For now, we mostly uses ffmpeg with vp8 + h264 so yeah the list is okay.

The other things we do:

AmarOk1412 commented 4 years ago

Fortunately, no more assertions with the current version, so the application is actually useful now.

Cool :)

ntninja commented 4 years ago

For now, we mostly uses ffmpeg with vp8 + h264 so yeah the list is okay.

The other things we do:

* Support nvcodec and cuvid for hardware acceleration

* Patch ffmpeg to support REMB packets for adaptative bitrate for video (https://git.jami.net/savoirfairelinux/ring-daemon/blob/master/contrib/src/ffmpeg/rtp_ext_abs_send_time.patch)

Sorry for being ignorant, but are these important? Is item 1 even available on Linux / in Flatpak sandbox?

Also please tell me what the whole dbus-c++ patching thing is about. Right now I'm just using the version built along with ring-daemon itself and I see no crashes (I did not test any intensive workloads however), so please elaborate why you added these changes.

ntninja commented 4 years ago

Some quick hack reveals that the camera will be detected when skipping UDev for device enumeration, however no matter which settings I select, dring always reports:

[1576264977.702| 55|media_decoder.cpp :128 ] Trying to open device /dev/video0 with format video4linux2, pixel format , size 160x120, rate 30.000000 [1576264977.702| 55|media_decoder.cpp :139 ] avformat_open_input failed: Invalid argument [1576264977.702| 55|video_input.cpp :220 ] Could not open input "/dev/video0" with status -22 [1576264977.703| 55|video_input.cpp :169 ] VideoInput closed

Looks like video support is still a long ways offf…

AmarOk1412 commented 4 years ago

Yeah np:

The thing is, if not in flatpak or snap, all packages succeed to get the video, so redoing this part to work in flatpak is not a priority. But still, don't really know the alternative. IMHO we can:

In both case I think it would need to communicate with the flatpak devs to understand what is the real issue here (or somebody who knows what flatpak is blocking)

At least:

Trying to open device /dev/video0 with format

This means that the video is discovered (and it's better than in my PR, because I didn't have access to the camera through the video_device_monitor

AmarOk1412 commented 4 years ago

For ffmpeg, the experience will be better if patched, if not, it will still work without any problem, but it's not full featured. It mostly depends on what is the strategy. Full featured / using upstream dependencies and avoid patching contribs.

ntninja commented 4 years ago

Thanks for detailed reply! I'll leave ffmpeg as-is for now then and focus on getting video (and Fedora…) working then. After this I'll look at it again. Since there are no issues regarding dbus as of now, I'll keep using the version shipped with Jami, thanks for clarifying that!

ntninja commented 4 years ago

Oh, and I should also mention that the Flatpak devs are working on exposing video devices using Pipewire in the short to mid-term, so eventually we hopefully can just require that and be done with the video problem (not available quite just yet unfortunately).

ntninja commented 4 years ago

Also regarding sandbox permissions:

  "--talk-name=org.freedesktop.secrets",
  "--talk-name=org.freedesktop.Notifications",
  "--talk-name=org.gnome.SettingsDaemon.MediaKeys",
  "--talk-name=org.mate.SettingsDaemon",
  "--talk-name=org.gnome.ScreenSaver",
  "--talk-name=org.cinnamon.ScreenSaver",
  "--talk-name=org.freedesktop.ScreenSaver",
  "--talk-name=com.canonical.Unity.Session",

Do you happen to know if we need all of the above d-bus endpoints available? From the looks of it, it wants to have libsecret (Password storage), libnotify-based notifications, GNOME-style media key support and the ability to keep the screen on. Is all of that actually used?

AmarOk1412 commented 4 years ago

Note: I am using Fedora 31 (i3 + x11, not Gnome + Wayland) right now (and I mainly use Fedora even if I have devices with debian or Ubuntu).

So I can build/test if needed (just need instructions because clearly I can't remember all the things I do)

I don't think Jami is compatible with Pipewire. The thing is with Wayland we encounter some issues (with webkitgtk if XDG_BACKEND is forced to x11 or clutter if not see https://git.jami.net/savoirfairelinux/ring-client-gnome/issues/1100). I can't find time since some months on the Gtk client and we think to make the Qt client (working on wayland + x11 without issues) the default one (see https://git.jami.net/savoirfairelinux/ring-client-gnome/issues/1114).

For the d-bus endpoint, I don't think we need ScreenSaver. But yeah at least libnotify (we use ayatana + another libnotifiy) and libsecret (don't think it's needed, but at 2am I can't really remember/verify) seems goodé

AmarOk1412 commented 4 years ago

hopefully pipewire support should be done. At least for recording screen (only available on x11 for now on Linux)

ntninja commented 4 years ago

I've just checked the source and behaviour for all these D-Bus interfaces and they don't seem to be used anywhere (except StatusNotifierWatcher and fdo.Notification). Thank you!

I've since shifted my focus to audio, do you have any idea what the following log could mean?

[1576318349.889| 123|sipcall.cpp :1053 ] [call:3787011654375363] stopping all medias [1576318349.889| 123|sipcall.cpp :906 ] [call:3787011654375363] startAllMedia() [1576318349.891| 123|audio_input.cpp :53 ] Creating audio input with id: 3787011654375363 [New Thread 0x7fff81ffb700 (LWP 161)] [1576318349.902| 123|audio_input.cpp :178 ] Switching audio source to match 'camera:///dev/video0' [1576318349.902| 123|audiosender.cpp :72 ] audioEncoder->openOutput rtp://10.0.2.15:30674 [NULL @ 0x7fffb8044f40] Requested output format 'rtp' is not a suitable output format [1576318349.903| 123|media_encoder.cpp :113 ] Failed to set payload type: Option not found [1576318349.903| 161|audio_input.cpp :72 ] Switching audio input to '/dev/video0' [1576318349.903| 123|media_encoder.cpp :504 ] [libopus] Using 4 threads [1576318349.903| 123|media_encoder.cpp :545 ] [libopus] Frame size 960

Thread 2 "dring" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff4e96700 (LWP 123)]
0x00007ffff70957f4 in avformat_new_stream () from /app/lib/ffmpeg-full/./libavformat.so.58
(gdb) bt full
#0  0x00007ffff70957f4 in avformat_new_stream () from /app/lib/ffmpeg-full/./libavformat.so.58
No symbol table info available.
#1  0x000055555581bad2 in jami::MediaEncoder::initStream (this=0x7fffb8002590, systemCodecInfo=..., framesCtx=0x0)
    at media_encoder.cpp:204
        lk = {_M_device = @0x7fffb80025d0}
        encoderCtx = 0x7fffb80168c0
        mediaType = <optimized out>
        stream = <optimized out>
#2  0x00005555557fb28a in jami::AudioSender::setup (this=0x7fffb80165d0, socketPair=...)
    at /usr/include/c++/9.2.0/bits/shared_ptr_base.h:1020
        codec = <optimized out>
        ms = {name = "audio sender", format = 1, isVideo = false, timeBase = {num_ = 1, den_ = 48000}, firstTimestamp = 0, 
          width = 0, height = 0, bitrate = 0, frameRate = {num_ = 0, den_ = 1}, sampleRate = 48000, nbChannels = 2, 
          frameSize = 960}
        codec = <optimized out>
#3  0x00005555557fba10 in jami::AudioSender::AudioSender (this=0x7fffb80165d0, id=..., dest=..., args=..., socketPair=..., 
    seqVal=<optimized out>, muteState=false, mtu=1252) at audio_sender.cpp:51
No locals.
#4  0x00005555557f837c in jami::AudioRtpSession::startSender (this=0x555555d29400)
    at /usr/include/c++/9.2.0/bits/unique_ptr.h:352
        newParams = {<std::__basic_future<jami::DeviceParams>> = {<std::__future_base> = {<No data fields>}, 
            _M_state = std::shared_ptr<std::__future_base::_State_baseV2> (use count 3, weak count 0) = {
              get() = 0x7fffb80232b0}}, <No data fields>}
#5  0x00005555557f9527 in jami::AudioRtpSession::start (this=0x555555d29400, rtp_sock=..., rtcp_sock=...)
    at audio_rtp_session.cpp:168
        lock = {_M_device = @0x555555d29408}
#6  0x00005555557d6343 in jami::SIPCall::startAllMedia (this=0x555555dc1870)
    at /usr/include/c++/9.2.0/bits/shared_ptr_base.h:1169
        local = @0x7fffb80110d0: {type = jami::MEDIA_AUDIO, enabled = true, holding = false, addr = {addr = {addr = {
                sa_family = 2}, ipv4 = {sin_family = 2, sin_port = 12869, sin_addr = {s_addr = 3221225738}, 
                sin_zero = "\000\000\000\000\000\000\000"}, ipv6 = {sin6_family = 2, sin6_port = 12869, 
                sin6_flowinfo = 3221225738, sin6_addr = {s6_addr = '\000' <repeats 15 times>, u6_addr32 = {0, 0, 0, 0}}, 
                sin6_scope_id = 0}}}, codec = std::shared_ptr<jami::AccountCodecInfo> (use count 8, weak count 0) = {
            get() = 0x7fffec002ff0}, payload_type = 104, 
          receiving_sdp = "v=0\r\no=Alexander-NB 3785307143 0 IN IP4 […REDACTED…]\r\ns=Jami Daemon\r\nc=IN IP4 […REDACTED…]\r\nt=0 0\r\na=ice-ufrag:0d86f1ba\r\na=ice-pwd:[…REDACTED…]\r\nm=audio 17714 RTP/SAVP 104\r\na=rtpmap:104 opus/4"..., 
          bitrate = 0, rtp_clockrate = 48000, frame_size = 0, parameters = "", auto_quality = false, linkableHW = false, 
          crypto = {tag_ = "1", cryptoSuite_ = "AES_CM_128_HMAC_SHA1_80", srtpKeyMethod_ = "inline", 
            srtpKeyInfo_ = "[…REDACTED…]", lifetime_ = "", mkiValue_ = "", mkiLength_ = ""}}
        remote = @0x7fffb8011248: {type = jami::MEDIA_AUDIO, enabled = true, holding = false, addr = {addr = {addr = {
                sa_family = 2}, ipv4 = {sin_family = 2, sin_port = 53879, sin_addr = {s_addr = 251789322}, 
                sin_zero = "\000\000\000\000\000\000\000"}, ipv6 = {sin6_family = 2, sin6_port = 53879, 
                sin6_flowinfo = 251789322, sin6_addr = {s6_addr = '\000' <repeats 15 times>, u6_addr32 = {0, 0, 0, 0}}, 
                sin6_scope_id = 0}}}, codec = std::shared_ptr<jami::AccountCodecInfo> (use count 8, weak count 0) = {
            get() = 0x7fffec002ff0}, payload_type = 104, receiving_sdp = "", bitrate = 0, rtp_clockrate = 48000, 
          frame_size = 0, parameters = "", auto_quality = false, linkableHW = false, crypto = {tag_ = "1", 
            cryptoSuite_ = "AES_CM_128_HMAC_SHA1_80", srtpKeyMethod_ = "inline", 
            srtpKeyInfo_ = "[…REDACTED…]", lifetime_ = "", mkiValue_ = "", mkiLength_ = ""}}
        new_mtu = <optimized out>
        rtp = 0x555555d29400
        slot = {first = {type = jami::MEDIA_AUDIO, enabled = true, holding = false, addr = {addr = {addr = {sa_family = 2}, 
                ipv4 = {sin_family = 2, sin_port = 12869, sin_addr = {s_addr = 3221225738}, 
                  sin_zero = "\000\000\000\000\000\000\000"}, ipv6 = {sin6_family = 2, sin6_port = 12869, 
                  sin6_flowinfo = 3221225738, sin6_addr = {s6_addr = '\000' <repeats 15 times>, u6_addr32 = {0, 0, 0, 0}}, 
                  sin6_scope_id = 0}}}, codec = std::shared_ptr<jami::AccountCodecInfo> (use count 8, weak count 0) = {
              get() = 0x7fffec002ff0}, payload_type = 104,
ntninja commented 4 years ago

Ok nvm, I found the answer/error message: https://stackoverflow.com/a/30244555/277882

I guess not building our own version of ffmpeg is not an option now. (It probably shouldn't have crashed on this however.) – Good news is that audio calls now work!

ntninja commented 4 years ago

@AmarOk1412: Did you ever try to compile Jami on ARM? I get an FFMPEG error there:

[…]
../../contrib/src/ffnvcodec/rules.mak:13: .sum-ffnvcodec not implemented
touch .sum-ffnvcodec
rm -f -R ffnvcodec    && tar xJf ../../contrib/tarballs/ffnvcodec-n9.0.18.1.tar.xz  
mv ffnvcodec-n9.0.18.1 ffnvcodec && touch ffnvcodec
cd ffnvcodec && CC="gcc" CXX="g++" LD="ld" AR="ar" CCAS="gcc -c" RANLIB="ranlib" STRIP="strip" PATH="/app/bin:/run/build/ring-client-gnome/daemon/extras/tools/build/bin:/app/bin:/usr/bin" CPPFLAGS=" -I/app/include -fPIC" CFLAGS="-O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -fasynchronous-unwind-tables -fstack-clash-protection -Os -g -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/app/include -DNDEBUG=1 -O3  -fPIC" CXXFLAGS="-O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -fasynchronous-unwind-tables -fstack-clash-protection -Os -g -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/app/include -DNDEBUG=1 -O3 -std=c++14 -fPIC" LDFLAGS="-L/app/lib -Wl,-z,relro,-z,now -Wl,--as-needed -fstack-protector-strong -Wl,-z,relro,-z,now -L/app/lib -L/app/lib" DESTDIR=/app make install PREFIX=""
make[1]: Entering directory '/run/build/ring-client-gnome/daemon/contrib/native/ffnvcodec'
sed 's#@@PREFIX@@##' ffnvcodec.pc.in > ffnvcodec.pc
install -m 0755 -d '/app/include/ffnvcodec'
install -m 0644 include/ffnvcodec/*.h '/app/include/ffnvcodec'
install -m 0755 -d '/app/lib/pkgconfig'
install -m 0644 ffnvcodec.pc '/app/lib/pkgconfig'
make[1]: Leaving directory '/run/build/ring-client-gnome/daemon/contrib/native/ffnvcodec'
touch .ffnvcodec
touch -r .ffnvcodec .dep-ffnvcodec
cd ffmpeg && CC="gcc" CXX="g++" LD="ld" AR="ar" CCAS="gcc -c" RANLIB="ranlib" STRIP="strip" PATH="/app/bin:/run/build/ring-client-gnome/daemon/extras/tools/build/bin:/app/bin:/usr/bin" CPPFLAGS=" -I/app/include -fPIC" CFLAGS="-O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -fasynchronous-unwind-tables -fstack-clash-protection -Os -g -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/app/include -DNDEBUG=1 -O3  -fPIC" CXXFLAGS="-O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -fasynchronous-unwind-tables -fstack-clash-protection -Os -g -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/app/include -DNDEBUG=1 -O3 -std=c++14 -fPIC" LDFLAGS="-L/app/lib -Wl,-z,relro,-z,now -Wl,--as-needed -fstack-protector-strong -Wl,-z,relro,-z,now -L/app/lib -L/app/lib" ./configure \
    --extra-cflags="-O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -fasynchronous-unwind-tables -fstack-clash-protection -Os -g -fstack-protector-strong -D_FORTIFY_SOURCE=2 -I/app/include -DNDEBUG=1 -O3 " \
    --extra-ldflags="-L/app/lib -Wl,-z,relro,-z,now -Wl,--as-needed -fstack-protector-strong -Wl,-z,relro,-z,now -L/app/lib -L/app/lib" --cc="gcc" --pkg-config="pkg-config" --disable-everything --enable-zlib --enable-gpl --enable-swscale --enable-bsfs --disable-filters --disable-programs --disable-postproc --disable-protocols --enable-protocol=crypto --enable-protocol=file --enable-protocol=rtp --enable-protocol=srtp --enable-protocol=tcp --enable-protocol=udp --enable-protocol=unix --enable-protocol=pipe --disable-demuxers --disable-muxers --enable-muxer=rtp --enable-muxer=g722 --enable-muxer=h263 --enable-muxer=h264 --enable-muxer=hevc --enable-muxer=webm --enable-muxer=ogg --enable-muxer=pcm_s16be --enable-muxer=pcm_s16le --enable-demuxer=rtp --enable-demuxer=mjpeg --enable-demuxer=mjpeg_2000 --enable-demuxer=mpegvideo --enable-demuxer=gif --enable-demuxer=image_jpeg_pipe --enable-demuxer=image_png_pipe --enable-demuxer=image_webp_pipe --enable-demuxer=matroska --enable-demuxer=m4v --enable-demuxer=mp3 --enable-demuxer=ogg --enable-demuxer=flac --enable-demuxer=wav --enable-demuxer=ac3 --enable-demuxer=g722 --enable-demuxer=pcm_mulaw --enable-demuxer=pcm_alaw --enable-demuxer=pcm_s16be --enable-demuxer=pcm_s16le --enable-demuxer=h263 --enable-demuxer=h264 --enable-demuxer=hevc --enable-parser=h263 --enable-parser=h264 --enable-parser=mpeg4video --enable-parser=vp8 --enable-parser=vp9 --enable-parser=opus --enable-encoder=adpcm_g722 --enable-decoder=adpcm_g722 --enable-encoder=rawvideo --enable-decoder=rawvideo --enable-encoder=libx264 --enable-decoder=h264 --enable-encoder=pcm_alaw --enable-decoder=pcm_alaw --enable-encoder=pcm_mulaw --enable-decoder=pcm_mulaw --enable-encoder=mpeg4 --enable-decoder=mpeg4 --enable-encoder=libvpx_vp8 --enable-decoder=vp8 --enable-decoder=vp9 --enable-encoder=h263 --enable-encoder=h263p --enable-decoder=h263 --enable-encoder=mjpeg --enable-decoder=mjpeg --enable-decoder=mjpegb --enable-libspeex --enable-libopus --enable-libvpx --enable-libx264 --enable-encoder=libspeex --enable-decoder=libspeex --enable-encoder=libopus --enable-decoder=libopus --enable-decoder=flac --enable-decoder=vorbis --enable-decoder=aac --enable-decoder=ac3 --enable-decoder=eac3 --enable-decoder=mp3 --enable-decoder=pcm_u24be --enable-decoder=pcm_u24le --enable-decoder=pcm_u32be --enable-decoder=pcm_u32le --enable-decoder=pcm_u8 --enable-decoder=pcm_f16le --enable-decoder=pcm_f24le --enable-decoder=pcm_f32be --enable-decoder=pcm_f32le --enable-decoder=pcm_f64be --enable-decoder=pcm_f64le --enable-decoder=pcm_s16be --enable-decoder=pcm_s16be_planar --enable-decoder=pcm_s16le --enable-decoder=pcm_s16le_planar --enable-decoder=pcm_s24be --enable-decoder=pcm_s24le --enable-decoder=pcm_s24le_planar --enable-decoder=pcm_s32be --enable-decoder=pcm_s32le --enable-decoder=pcm_s32le_planar --enable-decoder=pcm_s64be --enable-decoder=pcm_s64le --enable-decoder=pcm_s8 --enable-decoder=pcm_s8_planar --enable-decoder=pcm_u16be --enable-decoder=pcm_u16le --enable-encoder=gif --enable-decoder=gif --enable-encoder=jpegls --enable-decoder=jpegls --enable-encoder=ljpeg --enable-decoder=jpeg2000 --enable-encoder=png --enable-decoder=png --enable-encoder=bmp --enable-decoder=bmp --enable-encoder=tiff --enable-decoder=tiff --enable-filter=scale --enable-filter=overlay --enable-filter=amix --enable-filter=amerge --enable-filter=aresample --enable-filter=format --enable-filter=aformat --enable-filter=fps --enable-filter=transpose --enable-filter=pad --enable-pic --extra-cxxflags=-fPIC --extra-cflags=-fPIC --target-os=linux --enable-indev=v4l2 --enable-indev=xcbgrab --enable-vdpau --enable-hwaccel=h264_vdpau --enable-hwaccel=mpeg4_vdpau --enable-vaapi --enable-hwaccel=h264_vaapi --enable-hwaccel=mpeg4_vaapi --enable-hwaccel=h263_vaapi --enable-hwaccel=vp8_vaapi --enable-hwaccel=mjpeg_vaapi --enable-encoder=h264_vaapi --enable-encoder=vp8_vaapi --enable-encoder=mjpeg_vaapi --enable-cuvid --enable-ffnvcodec --enable-nvdec --enable-nvenc --enable-hwaccel=h264_nvdec --enable-hwaccel=hevc_nvdec --enable-hwaccel=vp8_nvdec --enable-hwaccel=mjpeg_nvdec --enable-encoder=h264_nvenc --enable-encoder=hevc_nvenc --arch=aarch64 \
    --prefix="/app" --enable-static --disable-shared
tput: No value for $TERM and no -T specified
tput: No value for $TERM and no -T specified
ERROR: cuvid requested, but not all dependencies are satisfied: ffnvcodec
[…]

Does that ring any bell?

AmarOk1412 commented 4 years ago

Yeah, in fact a patch is coming for this. We will generate packages for raspbian and ffnvcodec is not compatible with arm.

https://review.jami.net/c/ring-daemon/+/13282

ntninja commented 4 years ago

Thanks! I have now brought a new build on the way that has working audio call support.

AmarOk1412 commented 4 years ago

Awesome!

ntninja commented 4 years ago

When you have time could you read through and leave a comment on https://gitlab.com/freedesktop-sdk/freedesktop-sdk/issues/941. I'm hoping to get a compatible version of FFMPEG built into the runtime at some point and it would be valuable to have your input on this as I can only guess as to why some of the FFMPEG things are needed by Jami.

AmarOk1412 commented 4 years ago

Looks ok for me.

And indeed, we use rtp+srtp.

I am not at all the media dev in Jami, but last thing we use is this:

Add RTP Absolute Send Time extension https://git.jami.net/savoirfairelinux/ring-daemon/blob/master/contrib/src/ffmpeg/rtp_ext_abs_send_time.patch

This patch is used to send REMB packets to auto adapt the video quality depending of the bitrate feedback sent by the peer.

AmarOk1412 commented 4 years ago

@alexander255 just to say that the comm team made a text for the app data and because the list (

  • ) is not parsed correctly, I've just pushed the change related: https://review.jami.net/c/ring-client-gnome/+/13397

    Merry xmas.

  • ntninja commented 4 years ago

    @AmarOk1412: Excellent that we can get something official here!

    I'd like to add however, that the new text feels kinda short. The displayed should be relatively complete description of the entire application and should make sense without further contents (think people browsing within their native software discovery application), something like https://play.google.com/store/apps/details?id=cx.ring may be more appropriate. Also this text is not just for Flatpak, but will very likely be used for Distro-versions of the application distributed.

    ^ Maybe you can forward this feedback to them.

    AmarOk1412 commented 4 years ago

    forwarded

    ntninja commented 4 years ago

    Regard that extra patch, how realistic would it be to upstream that directly to FFMPEG? They may not accept including an app-specific patch just for us.

    Merry Christmas to you as well!

    AmarOk1412 commented 4 years ago

    Which one? Arm, rtp absolute time?

    Arm is just our build so I think you talk about REMB. I don't know (the media dev is in holiday), but two possibilites:

    ntninja commented 4 years ago

    Yes, the REMB one. I'll add it to the FDO issue mentioning that Jami is trying to get it included upstream. Do you think the media dev could find some time soon to quickly review my issue at FDO? It's probably going to be a few weeks/months before there is any reply from the runtime devs, so I'd be very helpful if the listing and explanation of stuff were correct to help reduce unnecessary RTTs then.

    AmarOk1412 commented 4 years ago

    I will ping him when he will be back

    ntninja commented 4 years ago

    Thanks!

    ntninja commented 4 years ago

    @AmarOk1412: Where are these patches merged into? I can't find them on https://git.jami.net/savoirfairelinux/ring-client-gnome .

    AmarOk1412 commented 4 years ago

    https://git.jami.net/savoirfairelinux/ring-daemon/blob/master/contrib/src/ffmpeg/rtp_ext_abs_send_time.patch

    ring-daemon