GNOME Bugzilla – Bug 685483
Should check which codecs we actually support rather than hardcoding them
Last modified: 2018-05-22 15:46:33 UTC
Currently empathy-call's client file and code hardcodes that we support H264 which may be fault in a lot of install. We should remove the client file so MC will invoke empathy-call which will be able to check using FS's API if we actually support it or not.
I didn't find any Farstream API to get the list of supported codec. The closest thing seems to be the FsSession:codecs property but when empathy-call is starting it doesn't have any FsSession yet. Olivier: what's the best way to get the list of supported codecs?
There's no API for that.. I think we should just try making the call and fail if there are no common codecs.
What happens if we fail currently? a call out to the codec install library? a clear message what is the problem?
Ideally a call to the codec installer, but that's non-trivial as we'd have to add code to convert the SDP name into the name GStreamer expects.
(In reply to comment #2) > There's no API for that.. I think we should just try making the call and fail > if there are no common codecs. Could we add some API for that? The plan is to know if we should advertise or not that we support H264 so if the call fails after it's already too late. Another option would be to use gst_element_factory_find() but then we'll depend on some specific gst elements.
My idea is that if we don't have h.264, we should let the user install it like totem does instead of just hiding the problem.
Hmm, but maybe it would be a better user experience to not offer video calling, but instead have some kind of button or similar to kick off the codec finder? Also is really converting the SDP name to the needed GStreamer names that hard considering we don't really need a generic solution, in practice it is a known list of 5-6 codecs right?
(In reply to comment #6) > My idea is that if we don't have h.264, we should let the user install it like > totem does instead of just hiding the problem. Right, but until we live in the bright future when this will be easily doable, shouldn't we just stop claiming that we support H264 if we actually don't?
I guess one could easily create a FsRtpConference, a video FsSession, set the codec preferences and see if H.264 is in "codecs-without-config" property on the session. Probably the kind of functionality I should be adding to FsIO..
Cool, I opened https://bugs.freedesktop.org/show_bug.cgi?id=58828 requesting such API.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/empathy/issues/595.