Helping someone with their 20250616 Jami. The .264 encoder was selected on the receive side Windows 11 pro underpowered client (Advanced Settings) and the debug file read invalid data. I ticked a couple of the other codecs and they now have incoming video. The calling device was an iphone, no further details. I replicated the issue with win11 beta client on an i7 XPS Dell dev machine with all codecs selected. The client then used a Macbook (unk mdl/year/config) to call and there was no video or audio. I did not generate a log file for that yet. Let me know if that is needed.
***in my overnight thinking about this, the receive client machine is seriously underpowered. This may explain the issue, however there is no easy method to set both clients to low(er) video/audio resolution/sampling interval hence bandwidth and cpu cycles when there is a problem like this.
debug file for reference:
How does Jami work when negotiating audio / video call setup? What happens if advanced settings preclude matched codecs (if that is what happened)?
And if the data is invalid (continuously) in the debug, surely there is some bump to the clients at both ends to notify?
With kind regards,
Rob
Is there something unspoken here like what is the preferred order of the codecs?
If there is a mix of calling devices, and they have their codecs ordered differently, does this end up in a mess?
In order to speed up development/improvement of the Jami product, I put forth a general idea:
-
Implement a feature as part of the jami client that switches on a document issue dialog, which asks user to select the symptom(s) of the problem (no incoming video, no outgoing video, video quality, repeat for audio, user interface, call setup/establishment, etc…).
-
Once engaged this mode will do the following:
Assign a problem identifier (PI) and display somewhere on UI
On the local device enable specific diagnostics to be logged with PI
if in a call,
tag the call in the UI with the PI
signal the other end to Enable Specific Diagnostics to be Logged with PI (ESDLPI)
if call attempt, signal remote end if/once reachable ESDLPI
-
When user is finished with tests
(now called tests because we have enrolled user in our test program)
user can click on UI mode display and collected data from both (or more) clients is sent/uploaded to a reporting interface/depository. The data should have enough information to recreate the issue(s). Metrics on how well the video rate adapter is performing as well as a running error/gap stats.
-
Injected video/audio test frames (specially tagged if they could be included in same stream) could be sent at intervals bidirectionally that would be representative of the network quality. Another approach to this would be to add/log codec error detection/correction
-
Lastly, when something isn’t working … wouldn’t it be nice to have a loopback endpoint to call? That way any user can call and test their system without bothering anyone else, not building up internal frustration energy, being able to solve their issue without anyone knowing they are an idiot for changing all of their settings randomly or purposefully …whatever!
If this endpoint feature also included functions to:
report/“reset” settings if call setup/connect/etc doesn’t work
report/adjust vid/aud settings to current up/dn bandwidth
report/adjust vid/aud settings to available cpu cycles
(for bw and cpu adjust so packets not dropping and crf is reasonable)
report/adjust for bandwidth asymmetry
Seriously, there must be a UX help user approach to make Jami better than ever!
With kind regards,
Rob