Closed AmarOk1412 closed 4 years ago
Started test build 9240
Build 9240 failed
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.
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.
No problem, this was already quite helpful nonetheless.
Some questions about the stuff you did though:
dbus-c++
about? What does it fix?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.
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.
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.)
For now, we mostly uses ffmpeg with vp8 + h264 so yeah the list is okay.
The other things we do:
Fortunately, no more assertions with the current version, so the application is actually useful now.
Cool :)
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.
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…
Yeah np:
hardware acceleration is a great thing to have. In video calls, you will use the GPU, not the CPU if available
Auto bitrate support is pretty important. This avoid video drops in calls and adjust the bitrate with the info the peer is sending. In a low connectivity env, it will be cool.
For dbus. I don't really rembember. If your version is working, and if you can access to the dbus inside your flatpak via d-feet (session bus, cx.ring.Ring) for example, I think you can leave as it is :)
I saw a lot of issues with steam about joysticks plug/unplug. Is this still the case? Snap has the same issue. Not sure how to solve this. Jami uses v4l2 + udev to get available devices: https://git.jami.net/savoirfairelinux/ring-daemon/blob/master/src/media/video/v4l2/video_device_monitor_impl.cpp
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
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.
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!
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).
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?
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é
hopefully pipewire support should be done. At least for recording screen (only available on x11 for now on Linux)
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,
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!
@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?
Yeah, in fact a patch is coming for this. We will generate packages for raspbian and ffnvcodec is not compatible with arm.
Thanks! I have now brought a new build on the way that has working audio call support.
Awesome!
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.
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.
@alexander255 just to say that the comm team made a text for the app data and because the list (
Merry xmas.
@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.
forwarded
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!
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:
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.
I will ping him when he will be back
Thanks!
@AmarOk1412: Where are these patches merged into? I can't find them on https://git.jami.net/savoirfairelinux/ring-client-gnome .
NOTE: THIS IS STILL A DIRTY WIP
TODOS:
Fixes #6 #4